Re: LTO, LLVM, etc.

[Chris Lattner <clattner at apple dot com>]

On Dec 5, 2005, at 5:43 PM, Mark Mitchell wrote:
> Chris Lattner wrote:
> > I totally agree with Steven on this one.  It is *good* for the
> > representation hosting optimization to be different from the
> > representation you use to represent a program at source level.   
> > The  two
> > have very different goals and uses, and trying to merge them into   
> > one
> > representation will give you a representation that isn't very   
> > good for
> > either use.
>
> I don't think that's entirely true.  One of the nice things about  
> WHIRL,
> at least in theory, is that the representation is gradually lowered
> throughout the compiler, but is never abruptly transitioned, as with
> GCC's Tree->RTL conversion.  So, it's easier to reuse code, instead of
> having a Tree routine and an RTL routine that do "the same thing",  
> as we
> do in several places in GCC.

I understand where you are coming from here, and agree with it.   
There *is* value to being able to share things.

However, there is a cost.  I have never heard anything good about  
WHIRL from a compilation time standpoint: the continuous lowering  
approach does have its own cost.  Further, continuous lowering makes  
the optimizers more difficult to deal with, as they either need to  
know what 'form' they are dealing with, and/or can only work on a  
subset of the particular forms (meaning that they cannot be freely  
reordered).

> > In particular, the optimization representation really does want
> > something in "three-address" form.  The current tree-ssa   
> > implementation
> > emulates this (very inefficiently) using trees, but at  a significant
> > performance and memory cost.  The representation you  want for
> > source-level information almost certainly *must* be a tree.
>
> Instead, it's a long-winded way of saying that I don't agree that
> there's any inherent benefit to using completely different
> representations, but that I do agree that one wants the right
> representation for the job, and that Tree-SSA is not the best
> representation for optimization.  So, if Tree-SSA is not replaced, it
> will almost certainly need to evolve.

What sort of form do you think it could/would reasonably take? [1]   
Why hasn't it already happened?  Wouldn't it make more sense to do  
this work independently of the LTO work, as the LTO work *depends* on  
an efficient IR and tree-ssa would benefit from it anyway?

-Chris

1. I am just not seeing a better way, this is not a rhetorical question!