Merge Request: LLVM Code Generator for GHC

[Ian Lynagh]

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