LTO, LLVM, etc.

[Chris Lattner]

On Dec 5, 2005, at 5:27 PM, Mark Mitchell wrote:
> Steven Bosscher wrote:
>> IMVHO dumping for "export" and front-end tools and for the optimizers
>> should not be coupled like this.  Iff we decide to dump trees, then I
>> would hope the dumper would dump GIMPLE only, not the full front end
>> and middle-end tree representation.

> It's not that I would object to waking up one day to find out that the
> C++ front-end no longer used Tree, but it just doesn't seem very
> compelling to me.

I agree with you.  The 'tree' data structure is conceptually what we  
want for the front-ends to represent the code.  They are quite  
similar in spirit to many AST representations.

>> Sharing a tree dumper between the front ends and the middle-end would
>> only make it more difficult again to move to sane data structures for
>> the middle end and to cleaner data structures for the front ends.

> The differences between GIMPLE and C++ Trees are small, structurally;
> there are just a lot of extra nodes in C++ that never reach  
> GIMPLE.  If
> we had a tree dumper for one, we'd get the other one almost for free.
> So, I don't think sharing the tree dumper stands in the way of  
> anything;
> you can still switch either part of the compiler to use non-Tree
> whenever you like.  You'll just need a new dumper, which you would  
> have
> wanted anyhow.

The point that I'm arguing (and I believe Steven agrees with) is that  
trees make a poor representation for optimization.  Their use in tree- 
ssa has lead to a representation that takes hundreds of bytes and  
half a dozen separate allocations for each gimple operation.  From  
the efficiency standpoint alone, it doesn't make sense to use trees  
for optimization.

Further, I would point out that it actually HURTS the front-ends to  
have the optimizers using trees.  We are getting very close to the  
time when there are not enough tree codes to go around, and there is  
still a great demand for new ones.  Many of these tree codes are  
front-end specific (e.g.  BIND_EXPR and various OpenMP nodes) and  
many of them are backend specific (e.g. the various nodes for the  
vectorizer).  Having the front-end and the back-end using the same  
enum *will* have a short term cost if the size of the tree enum field  
needs to be increased.

-Chris