This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LLVM/GCC Integration Proposal
- From: Chris Lattner <sabre at nondot dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 18 Nov 2005 22:43:12 -0600 (CST)
- Subject: Re: LLVM/GCC Integration Proposal
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/