GHC-specific alias analysis for the LLVM backend
davidterei at gmail.com
Fri Sep 30 12:55:48 CEST 2011
Given the problems with dynamically linking in I wonder if it may be
worth while trying to get LLVM to include it? Probably not as it will
make it harder for us to tweak but an idea to consider.
Are you able to provide some performance numbers at this point? I'll
have a play around with the code myself tomorrow but am very excited.
On 30 September 2011 01:54, Max Bolingbroke <batterseapower at hotmail.com> wrote:
> Hi GHCers,
> As those of you who use the LLVM backend know, it often doesn't
> optimise as aggressively as you would like. The reason for this is
> often to do with aliasing. I've written a blog post outlining the
> problem and a solution, in the form of a GHC-specific alias analyser
> that tells LLVM that the heap does not alias with the stack:
> I think it might be desirable to have this pass in GHC, so we can use
> it whenever the user compiles with -fllvm. Perhaps someone could help
> me make the build system do what I want, though? Basically, if the
> LLVM backend is enabled I need to be able to compile a single C++ file
> to a .dynlib/.so/.dll, linking it against the LLVM .dynlib. This
> shared object must also be installed onto the user's system by "make
> install", and the compiler must know the fully-qualified path to that
> .dynlib so that I can have the driver pipeline invoke LLVM's "opt"
> tool with the path from which to dynamically load the custom pass.
> My previous experiences with the build system have not been good, so
> I'm a bit lost as to where to start with all this!
> Any guidance much appreciated,
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc