On Fri, Feb 19, 2010 at 01:25:58PM +1100, Manuel M T Chakravarty wrote: > David wrote, > > > 2. The back-end has a LLVM binding of sorts, this binding is similar in > > design to say the Cmm representation used in GHC. It represents the LLVM > > Assembly language using a collection of data types and can pretty print it > > out correctly. This binding lives in the 'compiler/llvmGen/Llvm' folder. > > Should this binding be split out into a separate library? > > That library would be a build requirement for GHC, then. It may be useful to > separate it out for other projects that want to use it, but for GHC, I don't > think it would help anything, so I wouldn't worry about that until somebody > actually wants to use it for something else.
I would say that if the LLVM binding is currently easy to split out then it would be worth doing so. Otherwise it'll probably end up getting entangled with GHC-specific code. Also, I suspect someone else wanting an LLVM binding is more likely to make their own than to try to separate out GHC's. > > 3. As mentioned above, LLVM needs to be patched to work with a registered > > build of GHC. If the llvm back-end was merged, how would this be handled? I > > would suggest simply carrying the patch with some instructions on how to > > use it in the GHC repo. People using GHC head could be expected to grab the > > LLVM source code and apply the patch themselves at this stage. > > I think, we should bundle LLVM with GHC and auto apply the patch at build > boot time That sounds like it would be a pain to maintain when new LLVM releases come out. Is this patch something that LLVM upstream are likely to accept? Thanks Ian _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
