Good! Why is this an *analysis*? Why can't we simply declare to LLVM that certain things don't alias?
At the moment we print out ascii stuff which LLVM parses. Would it be easier to call LLVM directly via an API? And if it is an analysis, how are the results expressed to LLVM? Simon | -----Original Message----- | From: [email protected] [mailto:[email protected]] On Behalf Of | Max Bolingbroke | Sent: 30 September 2011 09:54 | To: GHC Development Mailing List | Subject: GHC-specific alias analysis for the LLVM backend | | 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
