Re: LLVM/GCC Integration Proposal

[Chris Lattner <sabre at nondot dot org>]

Daniel Jacobowitz writes:
> > As describe above, we won't support every target that GCC currently
> > does.  Three options are possible:

> Chris tells me that an LLVM->GIMPLE translator wouldn't have target
> dependencies.  I'm not 100% sure I buy that, but I'll take it as given
> for now (if not they should be pleasantly small).  So suppose we
> implement that.  It seems like a much better choice than RTL anyway.

I'm not sure exactly what you mean by target dependencies, but everything 
target dependent has to (by definition) be represented in the LLVM code 
already.  LLVM makes things like "implicitly passing a pointer when 
returning a struct" explicit in the representation, as well as funny ABI 
things like passing FP values in integer registers.

Given that this is already handled, translating to GIMPLE should be quite 
straight-forward.  GIMPLE and LLVM are really quite close to each other: 
I've built the LLVM to GIMPLE translator in about 2-3 weeks, and most of 
that time has been figuring out target hooks to do the target-specific 
lowering correctly.

> (A) What bits of LLVM would we be bypassing, and how badly would we
> miss them?

A system that used LLVM for the mid-level IR and then converted back to 
RTL would enjoy all of the benefits of the LLVM IR (compactness, ease of 
manipulation, testability, modularity, etc) but would just not have the 
code generator.  I see this as a great intermediate point that would be 
good for migrating targets if and when desired.

For example, targets that the GCC backend currently serves well could stay 
with the RTL backend until the LLVM targets improve (or exist :) ), and 
those targets that are better served by the LLVM backend could use it. 
One example area where LLVM excels is lowering of code in the backend 
(e.g. promoting small values to GPRs for RISC machines, and breaking up 
large integer values for targets without 64-bit registers).

> (B) What bits of GCC would we be bypassing, and how badly would we miss
> them?
> Presumably, many of the shiny new tree optimizers.  Ow.  But GCC was
> not in any state to do this sort of surgery a year ago, I think.

Quite true.  I'll let others comment about the implications of that.

One very important point is that because GIMPLE and LLVM are very similar 
in spirit, optimizers could easily be moved over (just like the LLVM 
reassociation pass was moved over to GCC).  I assert that the 
*implementation* of the LLVM IR is lighter weight than the current 
"tree"-based GIMPLE IR (though they are both very close in spirit to each 
other), which helps with memory usage and compile times.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/