Re: removal of static vars analysis code from mainline.

[Jan Hubicka <jh at suse dot cz>]

> Jan, I sent you directly (about 15 minutes ago) a patch that is the same 
> as I applied to the mainline but fixed up for the current tree profiling 
> branch.
> 
> I am going to rework my new code to the for the tree profiling branch 
> but I am going to change the names of most of the functions so that they 
> are a little saner and fit with the naming scheme better.  I will also 
> fix the ggc problems you noticed today.

Our lines has crossed again.  That patch is, of course, OK for tree
profiling branch.

Honza
> 
> Kenny
> 
> Jan Hubicka wrote:
> 
> >>Mark Mitchell wrote:
> >>
> >>   
> >>
> >>>Kenneth Zadeck wrote:
> >>>
> >>>     
> >>>
> >>>>Mark,
> >>>>
> >>>>Jan has explained to me that it appears to be impossible for me find 
> >>>>all of the variables in the mainline branch.  It appears that at the 
> >>>>time cgraph is run, some of the variables have disappeared from the 
> >>>>trees and are only in the asm file and that the front ends are still 
> >>>>keeping some of the variables a secret.
> >>>>
> >>>>He claims to have fixed these problems (or at least all the ones he 
> >>>>has found) on the tree profiling branch but believes that is not 
> >>>>worthwhile to port onto the mainline so the correct solution appears 
> >>>>to be remove my code from the mainline and work on the tree profiling 
> >>>>branch until things open back up on the mainline.
> >>>>
> >>>>Enclosed is a patch to remove my code. 
> >>>>       
> >>>>
> >>>How sad.  Patch OK.
> >>>
> >>>     
> >>>
> >>I would feel a lot worse if Jan had not fixed the code in tree-profile 
> >>branch.  I will make it work there and get it into 4.1.
> >>   
> >>
> >
> >Kenny,
> >I've been thinking about your code in the train now and I think sad
> >problem we run into was that I didn't realized what you really need for
> >your analysis (ie we always chatted only about the functions, not
> >variables tought it is trivial to notice that these are needed too) and
> >you simply assumed sane interfaces on the mostly half finished IPA
> >interface to be sane.
> >
> >Your work is actually the second IPA pass we have (I implemented only
> >inlining) and it is very first that cares about the variables and thus
> >you sadly run into more issues than you would do if you choosed some
> >less pioneering work ;))
> >
> >Since tree-profiling really fixes all the underlying problems I
> >understand to, I would suggest that I will avoid merging the revert to
> >the branch and apply modified version of your patch introducing master
> >clones (I would like to keep the files named ipa-something).
> >(steven, is that OK with you if I do so this week before cfg inliner or
> >shall I wait?)
> >
> >I will try to then look into your code and hook it into current
> >tree-profiling interface for IPAs (ie the passmanager and the cgraph
> >structures) and send you the patch for review.  This way I guess I will
> >learn how exactly the aliasing work and hopefully will ensure if
> >something is still wrong and I think I can give you the more complette
> >testcase how things work so you can easier comment on it.
> >Last week I made similar experiment with the Razya's ipcp
> >implementation and it was ineed interesting try.
> >
> >Does that sound sane to you?
> >Honza
> > 
> >
> >>Thanks for the speedy review.
> >>
> >>kenny
> >>   
> >>