This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LLVM/GCC Integration Proposal

On 11/19/05, Daniel Jacobowitz <> wrote:
> On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> > * This will not support <some target>!
> >
> > As describe above, we won't support every target that GCC currently
> > does.  Three options are possible:
> >
> > 1. We (the GCC community) could build an LLVM to GIMPLE translator.
> > This would probably take about as much work as the GIMPLE -> LLVM
> > translator (about  4000 LOC), which is not a huge project.
> > 2. We could build an LLVM to RTL translator.
> Let's run with the hypotheticals for a bit here... I have questions for
> both Chris and for GCC maintainers.
> 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.
> (A) What bits of LLVM would we be bypassing, and how badly would we
> miss them?
> I know it has its own register allocation and instruction selection,
> and they have advantages and disadvantages relative to the existing
> ones.  We could either take advantage of those as a framework to
> modernize GCC's, or move on with Andrew's new design to modernize
> GCC's.

I would propose to even think of doing only IPO at LLVM and go back to
gimple for the rest of the tree-ssa pipeline.  At least that should be possible.
Would we get link-time optimization this way, or is the LLVM link-time
optimization architected differently?

Also, integrating LLVM addresses the weakness of our middle-end IR, but
stays with this IR for our frontends.  Only the Ada frontend seems to be
in a state to maybe support direct frontend IR to LLVM translation.  So
the hard remaining parts would still be to convert the frontends to IRs
suiting them well and only then we would be able to get rid of (old) trees
completely.  But maybe such modular frontends would raise concerns of
the FSF again.

It's good to see the LLVM integration experiment done, and having parts
of that integration moved to mainline (like C++ support, or even the
LLVM backend(!) parts) would be nice.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]