GC-Safe Interprocedural Unboxing

Petersen, Leaf; Glew, Neal

doi:10.1007/978-3-642-28652-0_9

Cited by 8 publications

(11 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Accurate garbage collection imposes certain requirements on programs, needing information about which variables and object fields contain GC-managed references. Aggressive optimization such as inter-procedural object unboxing may change the GC status of variables and fields of objects [10,19]. The MIL language must support the tracking of such information, and the MIL optimizations must successfully maintain this information.…”

Section: Typesmentioning

confidence: 99%

“…The compiler also implements a number of inter-procedural representation optimizations using a field-sensitive, unification based flow analysis [10,19]. The main analysis can be roughly thought of as computing a set of equivalence classes on variables and object fields such that any two members of different equivalence classes can be guaranteed never to contain the same dynamic heap value.…”

Section: Optimizationsmentioning

confidence: 99%

“…The main analysis can be roughly thought of as computing a set of equivalence classes on variables and object fields such that any two members of different equivalence classes can be guaranteed never to contain the same dynamic heap value. Given such an analysis, the compiler can use the information computed by it to perform a number of representation optimizations in a GC safe manner [10,19]. For example, small, single-field, immutable objects (such as boxed floating point numbers) are replaced inter-procedurally by the contents of the object.…”

Section: Optimizationsmentioning

confidence: 99%

See 2 more Smart Citations

The Intel labs Haskell research compiler

Liu

Glew

Petersen

et al. 2013

Proceedings of the 2013 ACM SIGPLAN Symposium on Haskell

Self Cite

View full text Add to dashboard Cite

The Glasgow Haskell Compiler (GHC) is a well supported optimizing compiler for the Haskell programming language, along with its own extensions to the language and libraries. Haskell's lazy semantics imposes a runtime model which is in general difficult to implement efficiently. GHC achieves good performance across a wide variety of programs via aggressive optimization taking advantage of the lack of side effects, and by targeting a carefully tuned virtual machine. The Intel Labs Haskell Research Compiler uses GHC as a frontend, but provides a new whole-program optimizing backend by compiling the GHC intermediate representation to a relatively generic functional language compilation platform. We found that GHC's external Core language was relatively easy to use, but reusing GHC's libraries and achieving full compatibility were harder. For certain classes of programs, our platform provides substantial performance benefits over GHC alone, performing 2× faster than GHC with the LLVM backend on selected modern performance-oriented benchmarks; for other classes of programs, the benefits of GHC's tuned virtual machine continue to outweigh the benefits of more aggressive whole program optimization. Overall we achieve parity with GHC with the LLVM backend. In this paper, we describe our Haskell compiler stack, its implementation and optimization approach, and present benchmark results comparing it to GHC.

show abstract

Section: Typesmentioning

confidence: 99%

Section: Optimizationsmentioning

confidence: 99%

Section: Optimizationsmentioning

confidence: 99%

See 1 more Smart Citation

The Intel labs Haskell research compiler

Liu

Glew

Petersen

et al. 2013

Proceedings of the 2013 ACM SIGPLAN Symposium on Haskell

Self Cite

View full text Add to dashboard Cite

show abstract

“…HRC performs a number of loop-based and representation-style optimizations [13,17], and is able to produce straight loop code for many Repa programs. This is a good fit for OpenCL because OpenCL does not allow recursive function calls.…”

Section: Implementing In Hrcmentioning

confidence: 99%

Native offload of Haskell repa programs to integrated GPUs

Liu

Day

Glew

et al. 2014

Proceedings of the 3rd ACM SIGPLAN Workshop on Functional High-Performance Computing

Self Cite

View full text Add to dashboard Cite

In light of recent hardware advances, general-purpose computing on graphics processing units (GPGPU) is becoming increasingly commonplace, and needs novel programming models due to GPUs' radically different architecture. For the most part, existing approaches to programming GPUs within a high-level programming language choose to embed a domain-specific language (DSL) within a host metalanguage and then implement a compiler that maps programs written within that DSL to code in low-level languages such as OpenCL or CUDA. An alternative, underexplored, approach is to compile a restricted subset of the host language itself directly down to OpenCL/CUDA. We believe more research should be done to compare these two approaches and their relative merits. As a step in this direction, we implemented a quick proof of concept of the alternative approach. Specifically, we extend the Repa library with a computeG function to offload a computation to the GPU. As long as the requested computation meets certain restrictions, we compile it to OpenCL 2.0 using the recently added feature for shared virtual memory. We can successfully run nine benchmarks on an Intel integrated GPU. We obtain the expected performance from the GPU on six of those benchmarks, and are close to the expected performance on two more. In this paper, we describe an offload primitive for Haskell, how to extend Repa to use it, how to implement that primitive in the Intel Labs Haskell Research Compiler, and evaluate the approach on nine benchmarks, comparing to two different CPUs, and for one benchmark to handwritten OpenCL code.

show abstract

“…Many standard compiler optimizations have been implemented in the compiler, including loop-invariant code motion and a very general simplifier in the style of Appel and Jim [2]. The compiler also implements a number of interprocedural representation optimizations using a field-sensitive flow analysis [11]. The compiler generates output in a modified extension of the C language called Pillar [1].…”

Section: Intel Labs Haskell Research Compilermentioning

confidence: 99%

Automatic SIMD vectorization for Haskell

2013

Self Cite

View full text Add to dashboard Cite

Expressing algorithms using immutable arrays greatly simplifies the challenges of automatic SIMD vectorization, since several important classes of dependency violations cannot occur. The Haskell programming language provides libraries for programming with immutable arrays, and compiler support for optimizing them to eliminate the overhead of intermediate temporary arrays. We describe an implementation of automatic SIMD vectorization in a Haskell compiler which gives substantial vector speedups for a range of programs written in a natural programming style. We compare performance with that of programs compiled by the Glasgow Haskell Compiler.

show abstract

GC-Safe Interprocedural Unboxing

Cited by 8 publications

References 10 publications

The Intel labs Haskell research compiler

The Intel labs Haskell research compiler

Native offload of Haskell repa programs to integrated GPUs

Automatic SIMD vectorization for Haskell

Contact Info

Product

Resources

About