This is the mail archive of the
mailing list for the GCC project.
Re: IPA merge part 1: localize SSA variables
On Fri, 2006-11-17 at 11:43 +0100, Jan Hubicka wrote:
> > 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
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.