This is the mail archive of the gcc@gcc.gnu.org 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: Thoughts on LLVM and LTO


On Tue, 22 Nov 2005, Daniel Jacobowitz wrote:
The initial impression I get is that LLVM involves starting from scratch.
I don't quite agree that this is necessary.  One of the engineering
challenges we need to tackle is the requirement of keeping a fully
functional compiler *while* we improve its architecture.

Most of your concerns seem to be based on this impression; I don't think it's right. I'll keep this brief since others can probably answer the details more accurately than I can.

FWIW, I completely agree with Daniel's message here.


LLVM as a backend, i.e. replacing everything from GIMPLE -> assembly,
would involve a lot of starting from scratch.  e.g. your later example
of limited target support.  One of the options Chris proposed is
an optional GIMPLE -> LLVM -> GIMPLE process, in which:

Correct. I think that this is, by far, the most logical first step. As the LLVM code generators mature, enabling them on a per-target basis can make sense. If the GCC RTL backend improves (e.g. with the new RA design), perhaps the transition will never occur.


(A) the LLVM step is only necessary for optimization - I like this for
lots of reasons, not least being that we could bootstrap without a C++
compiler.

Great point.


(B) the LLVM register allocator, backend, et cetera would be optional
or unused, and the existing GCC backends would be used instead.  Which
are there today, need some modernizing, but work very well.

Exactly.


The LLVM -> GIMPLE translator does not exist yet; I believe Chris has a
prototype of the GIMPLE -> LLVM layer working, and it took him under a
month.  I've been convinced that the opposite direction would be as
straightforward.  That's something a sufficiently motivated developer
could hack out in the course of this discussion.

It took under a month while multitasking and doing several other things :). I will send out the patch for some concrete ideas of what it involves.


From what I understand, LLVM has never been used outside of a research
environment and it can only generate code for a very limited set of
targets.  These two are very serious limitations.

LLVM is indeed very new. At this point I believe it has been used outside of a research environment, but I can't say how thoroughly.

Yes, it has been used by several industrial groups, e.g. people targeting unconventional devices and as a other things (JIT compiler for shaders in a graphics program). Apple is investing in it as well as mentioned before.


Finally, I would be very interested in timelines.  Neither proposal
mentions them.  My impression is that they will both take roughly the same
amount of time, though the LLVM approach (as described) may take longer
because it seems to have more missing pieces.

My personal goal is to have debug info, vectorization, and inline asm fully working by Summer 2006, assuming no help outside of what Apple is investing.


In terms of bigger goals, I intend to be compiling all of OS/X by next December (again assuming no major help).

These are somewhat safe/conservative goals, but they should give some indication for my plans. With help, they would be significantly moved up. :)

-Chris

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


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