Re: IPA merge part 1: localize SSA variables

[Jan Hubicka <jh at suse dot cz>]

Hi,
I hope to update the patch for final form today.
> 
> It might not be a consistent mechanism, but it is consistent in that it
> is applying abstraction. If we even need to change the implementation of
> 'ssa_names', we have a couple of macros to change. If we ever need to
> look into more than one ssa_name vector at a time (who knows what we'll
> want to do in 5 years), it becomes trivial.

OK, at the moment I have somthing like 40 direct gimple_df accesses.  I
can guard those not present in tree-flow-inline accestors by macros
present in tree-flow with a comment tha thtey are meant for internal use
only.  Does this sound like sane plan?  Or shall I have double
abstraction for everything including the tree-flow-inline?

Also the tree-ssa necesarily holds bits internal to some unit (such as
list of free SSA names or tree-operand caches)
What about putting those into separate structures with overall accestor
to it, like gimple_operand_cache (cfun) returning pointer to the 
struct gimple_operand_cache having all the data?

I hope it will avoid the very flat "cfun" like structure with fields no
one really remembers what they are serving...
> 
>   
> > What precisely do you mean by more than one instance around?
> 
> If you want to be able to run that code on more than one function at a
> time. Not that I'm bringing the threading thread into this, but when its
> not really costing anything I generally like to write things as self
> contained as possible. I think of each pass as an object. This gives you
> more flexibility down the road should we discover we want to
> parallelize/pipeline the optimization passes. Something like cfg cleanup
> which gets called 6 or whatever times then needs to be completely self
> contained, or you couldn't have it running more than once.
> 
> Not that I think we are going to be doing that anytime soon, but you
> never know what might come up. I just figured if you are rewriting them
> already, we might as well do both at the same time.  And for what its
> worth, I think VAR_NAME(cfum) is slightly more readable than the long
> cfun->gimple..->varname string.
> 
> Im not religious about it or anything, but figured I would chip in with
> my 2 cents :-)

OK, we can leat towards privatizing the cfun pointers to be pass
specific, this is not that different anyway once we do have function
argument for all basic modification APIs.
> 
> 
> > > Bottom line is we don't need to make more work for ourselves, but when
> > > we are changing these things, we might as well go right to the
> > > (perceived :-)  end solution for those cases, in my opinion.
> > 
> > Agreed here. I am trying to know where the end sollution is to have some
> > consistent plan where to move the APIS rather than blindly volunteering
> > to rename every single variable in GCC this week :)
> 
> I would absolutely only do this to variables you are changing anyway. I
> don't see that we have to choose only one of functions and macros. I
> think we can use both, selecting whichever is more appropriate for any
> given var. If someone later decides that the other would be a better
> choice, it pretty easy to fix.  To me the consistency part is the
> abstraction, not the implementation.

Agreed here.
Honza
> 
> Andrew