proposal for compilation unil wide alias analyis

[Kenneth Zadeck]

I will like to try to pull this discussion back to the original point.

It is generally the excepted view that building ssa form and doing a few 
simple things turn out to be win enough to pay for them selves.  Having 
said that, the compilers that have generally done this have had very 
well engineered ssa implementations. The point is that if we are not 
there, we need to get there because it is the result of bad engineering 
rather than the premise being untrue. I think that it will take a few 
spins of some of the underlying datastructures to make it true in gcc.

When diego gets finished hacking the ccp in the way I suggested, this 
will almost certainly be true if you are using mudflaps, but I do not 
believe that is the popular path.

Having said that, my question is where do I start?  For the first round 
of this, it is certainly not necessary for me to analyze on top of ssa 
form, and in principal I could even work on the parse trees since all I 
need is to examine all of the addressing operators and operands in each 
function in the compilation unit before the actual transformations begin 
on any one function.

I think it is still an open question as to how important it is to have 
ssa form already built to start this.  Diego feels that this is where we 
will want to go because we will need this to do a flow sensitive 
follow-on to this analysis, and if we want to do the flow sensitive 
version of this after the flow insensitive version, we will need ssa 
form.  However we may do the flow sensitive analysis, we may not do it, 
we need to see how far I can get with the flow insensitive and more 
important, what significant cases we are miss by doing the flow 
insensitive analysis.

I do want to try to do my stuff in a manner that does not add to the 
ridgity of the compiler.  Stuart seems to be up to his izzards in 
alligators just trying to get his restructuring working and I do not 
want to add to his problems.  However, if I do my stuff at the parse 
tree level, this will be one more thing to bother with when he wants to 
merge his stuff.

Kenny

Mark Mitchell wrote:

> David Edelsohn wrote:
>
>>>>>>> Mark Mitchell writes:
>>>>>>>           
>>>>>>
>>
>> Mark> The Laffer curve argument (we can remove so much code in the 
>> optimizers Mark> so quickly that generating the code will actually be 
>> faster) seems to me Mark> like it is one that should be proven 
>> experimentally before we commit to it.
>>
>>     The argument that running some simple optimizations at -O0
>> decreases the amount of intermediate code and improves the compilation
>> speed of a compiler is proven experimentally by the IBM XLC Compiler.
>>  
>>
>> That is exactly the technique that XLC uses, with extremely careful,
>> empirical tests of which fine-grained optimizations should be enabled to
>> produce the best compilation performance[1].  We need to test that 
>> such a
>> technique has a beneficial effect on GCC, but there is no question that
>> the technique can be effective.
>>  
>>
> Agreed on both points -- both that it can be effective, and that we 
> need to demonstrate that it works with GCC.  I think we want to avoid 
> committing to (say) making the tree->rtl expanders accept only 
> SSA-form GIMPLE until we can demonstrate that it will be a 
> compile-time win to do so.
>