LTO, LLVM, etc.

[Chris Lattner]

On Dec 5, 2005, at 11:48 AM, Steven Bosscher wrote:
> On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
>> There is one advantage I see in the LTO design over LLVM's  
>> design.  In
>> particular, the LTO proposal envisions a file format that is  
>> roughly at
>> the level of GIMPLE.  Such a file format could easily be extended  
>> to be
>> at the source-level version of Tree used in the front-ends, so that
>> object files could contain two extra sections: one for LTO and one  
>> for
>> source-level information.  The latter section could be used for  
>> things
>> like C++ "export" -- but, more importantly, for other tools that need
>> source-level information, like IDEs, indexers, checkers, etc.
>>
>
> I actually see this as a disadvantage.
>
> 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.
>
> 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.

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.

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.

I think it is very dangerous to try to artificially tie link-time  
(and other) optimization together with source-level clients.  The  
costs are great and difficult to recover from (e.g. as difficult as  
it is to move the current tree-ssa work to a lighter-weight  
representation) once the path has been started.

That said, having a good representation for source-level exporting is  
clearly useful.  To be perfectly clear, I am not against a source- 
level form, I am just saying that it should be *different* than the  
one used for optimization.

-Chris