Re: Thoughts on LLVM and LTO

[Steven Bosscher <stevenb at suse dot de>]

On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> The initial impression I get is that LLVM involves starting from scratch.

I thought it would basically "only" replace the GIMPLE parts of the
compiler.  That is,

FE	-->	GENERIC	-->	LLVM	-->	RTL	--> asm
(trees)		(trees)

In the longer-term, you could maybe cut out the RTL part for targets
for which LLVM has its own backend.

This is not less evolutionary or revolutionary than tree-ssa was IMHO.


> With our limited resources, we cannot really afford to go off on a
> multi-year tangent nurturing and growing a new technology just to add a
> new feature.

It depends on who is going to invest these resources.  Would you want
to tell Apple they can't do this even though they can? ;-)


> LLVM is missing a few other features like debugging information and
> vectorization.  Yes, all of it is fixable, but again, we have limited
> resources.

A lot of work will have to go into debugging information even for GVM,
because debug info will have to go through the IPA machinery also, i.e.
be attached to the call graph, etc...

The vectorizer is a minor piece of code compared to IPA, or a complete
high-level optimizer.  And at least the ideas from the implementation
for GIMPLE that we have now may be re-usable.  (This is still the first
true "portable" vectorizer that I know of, maybe it's not only easy to
port to other targets, but also to other compilers! ;-)


> The lack of FSF copyright assignment for LLVM is a problem.

As is the lack of clear agreements on who would control this project,
e.g. going with LLVM also means we'll have to shuffle our reviewers'
privileges a bit.  After all, in the GCC community only Chris really
knows LLVM well enough -- so would that mean he'd get blanket approval
rights for the LLVM parts of the compiler?

This actually worries me more than the copyright question.


> A minor hurdle is LLVM's implementation language.  Personally, I would be
> ecstatic if we started implementing in C++.  However, not everyone in the
> community thinks this is a good idea.

And not everyone in the community thinks that sticking with C is a
good idea.  So far, the status quo was to stay with C because that's
what we have.  If someone puts up a large body of C++ code now, there
had better be good technical reasons against going with C++...


> But what are the 
> timelines?  What resources are needed?

Interesting questions.  Both projects obviously will take significant
effort.  But IIUC Chris has bits of the LLVM stuff already going, so
he has the head-start (like tree-SSA did when LLVM was introduced to
the GCC community, ironically? ;-) so maybe Chris can have a working
prototype implementation within, what, months?  The GVM plan could
take years to get to that point...

So my dummy prediction would be that the LLVM path would result in a
reasonable product more quickly than the GVM plan -- iff RTL stays.

Gr.
Steven