[PATCH] Fix part of pr25505
Thu Aug 31 22:12:00 GMT 2006
On Thu, 2006-08-31 at 17:00 -0400, Daniel Berlin wrote:
> > I still don;t. Just about every optimization deals with up to date
> > stmts. You have to go out of your way not to, like the renamer and
> > DOM.
> > In any case, if an optimization is dealing with out of date stmts, then
> > it ought to be manipulating the trees directly since the operand cache
> > isn't being used, not using FOR...OPERAND. Its for use when the normal
> > rules are being followed.
> > Checking for SSA_NAME within the body serves no real purpose. If you are
> > operating in an out-of-date state where you can get a non-ssa name, then
> > you are in a state where you are likely missing information by using
> > FOR...OPERAND.
> I don't disagree with this. I didn't write the code in question, and
> in fact I was the one that suggested it be changed.
> But i'll argue it's not clearly documented that they only return
> SSA_NAMES in places like tree-ssa.texi.
well, perhaps that could be explicitly spelled out if it isn't.
> It only talks about operands.
perhps thats the problem. operands are implicitly SSA_NAMEs. Thats all
the ssa operand cache ever deals with.
> It's not clear that these operands can only be SSA_NAMES.
> Naming the iterator "FOR_EACH_SSA_TREE_OPERAND" instead of
> "FOR_EACH_SSA_NAME_OPERAND" doesn't really help :)
The 'SSA' part says it returns an ssa_name. The TREE part you refer to
is the return type, it returns a TREE type. the USE and DEF types return
use_operand_p and def_operand_p types respectively.
so you get
FOR_EACH_SSA_TREE_OPERAND --> return tree types
FOR_EACH_SSA_USE_OPERAND --> return use_operand_p type
FOR_EACH_SSA_DEF_OPERAND --> return def_operand_p type
IF it could return non-ssa things, they'd be called
More information about the Gcc-patches