Great stuff! 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. Cheers, David On 30 September 2011 01:54, Max Bolingbroke <[email protected]> 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. > > 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, > Max > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
