On 30/09/2011 09:54, Max Bolingbroke 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:
http://blog.omega-prime.co.uk/?p=135

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.

This shouldn't be too hard, but you'll need to write some Makefile code to make it happen - we don't have anything like this already in the build system.

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!

I'd just make a subdirectory, put your .cpp file in it, and create a Makefile with rules to compile the file and install it. We should probably have a standard suffix rule for compiling .cpp files, so that things like SRC_CPLUSPLUS_OPTS can be used. Maybe you'll need some autoconf stuff to find the appropriate way to link against the LLVM libraries.

Cheers,
        Simon


_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to