Re: IPA merge part 1: localize SSA variables

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2006-11-17 at 11:43 +0100, Jan Hubicka wrote:
> Hi,
> > 
> > I think in these cases we don't need the read/write accessors, but
> > personally I would still like to see the access parameterized, so
> > instead of 
> > 
> >      VEC_quick_push (tree, cfun->gimple_df->ssa_names, NULL_TREE);
> >      cfun->gimple_df->free_ssanames = NULL;
> > 
> > we'd see
> > 
> >      VEC_quick_push (tree, SSA_NAMES (cfun), NULL_TREE);
> >      SSA_NAMES (cfun) = NULL;
> > 
> > It will save us work in the long run if we ever want to have more than
> > one instance around, for whatever reason.
> 
> I was considering the macros too, but combining the functional/macro
> abstraction didn't seem very consistent (ie we would end up with people
> writting macros for the public stuff too)

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.

  
> 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 :-)


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

Andrew