Re: LLVM/GCC Integration Proposal

[Daniel Berlin <dberlin at dberlin dot org>]

> (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.
> 
Probably true on both counts, but that wouldn't bother me, speaking as
someone who has written a lot of code for the tree optimizers.

The tree optimizers serve a purpose, they are not a goal unto
themselves.

If LLVM can serve that purpose, and do so better (or can be made to do
so better by moving improvements, extending it), while at the same time
bringing us other benefits, then the correct technical decision is to
move to it and replace the tree optimizers.

Realistically, we are going to end up doing as much surgery on the
GIMPLE and SSA representation (in terms of underlying data structures,
aliasing, re-writing and re-tooling optimizers, etc) in order to make
IPA work well, that 

1. It will probably be same amount of work (if not less work) to move
the improvements we have *to* LLVM, as all the surgery is going to take
to make IPA sane in GCC.  The only real difference is in what work you
are doing.

Building it from scratch may seem intellectually cool or whatever, but
from a technical standpoint, you aren't going to end up with an
infrastructure significantly better than LLVM's infrastructure is or
could be extended to be.

This is because anybody who has looked at compilers that have really
good IPA will tell you that you realistically can't do better in terms
of compile speed or memory usage, and that there is no magic that we
could perform that we can't make LLVM perform.

2. LLVM is here and we know it works, plus we know it's memory usage and
compile time on various applications.  All *we* have is guesses on how
much memory and compile time we can save based on what kind of surgery
you want to perform.  We have some idea for what it would take to make
IPA work well, and the rest is just expected to "become clear" as things
progress.

The bottom line is that  personally, I'm not in love with tree-ssa or my
code enough that I think ego should stand in the way of GCC making the
right decision.  I would hope others who have written the "shiny new
tree optimizers" feel the same way.  

I'd be just as happy moving data dependence, aliasing improvements (that
aren't subsumed by DSAA, which there are still plenty of :P), high level
loop transforms, better PRE, etc, from GCC to LLVM, as i would
re-tooling it to work with whatever we came up with from scratch.  

GCC has a lot of hard work ahead of it, whether we choose to build it
from scratch and do major surgery.  The question is whether you want to
take what we know works, or roll the dice and hope you can make
something better.  Unless y'all think you are going to get really lucky,
and do something nobody has been able to do yet, integrating LLVM is,
IMHO, a sound technical decision, even if it means replacing the tree
optimizers.

Just my 2 cents,
Dan