This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IPA merge part 1: localize SSA variables


On Mon, 2006-11-20 at 14:01 +0100, Jan Hubicka wrote:
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]