Re: proposal for compilation unil wide alias analyis

[Stuart Hastings <stuart at apple dot com>]

On Jun 27, 2004, at 6:34 AM, Kenneth Zadeck wrote:

> 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.

Thank-you for the thought.  :-)  I wouldn't have chosen that particular 
colorful description, although I do appreciate the humor (what exactly 
are izzards? ... nevermind :-).

In the interest of openness, here's my current status:

	C compiler bootstraps O.K. (well, it was fine last time I tried it)
	C++ EH regions still un-handled
	'remove_useless_stmts' pass still disabled

The basics of inlining one CFG into another seem to be done, with some 
attendant variable scope twiddling.  What needs doing next is the 
merging of EH regions for C++.

I'm currently (between interrupts here at Apple) moving some 
short-lived hashtables out of local statics in tree-eh.c and putting 
them into cfun->eh because I need them to be durable for inlining EH 
regions.  Alas, whilst moving various struct around in the GCC sources, 
I have offended the gengtype gods. who are now neglecting to define all 
of the corresponding garbage-collection functions.  There's always 
something...  ;-)

The 'remove_useless_stmts' tree-optimization pass needs revision to 
use/update a CFG.  I have it disabled for now.

I'd include my current patch here, but my gengtype troubles prevent me 
from linking cc1plus.

This week (6/28..7/02) is Apples trade show for developers.  I'm 
expected to attend most of the week, so I don't expect any big 
breakthroughs on this work.

stuart hastings
Apple Computer