[PATCH] Fix part of pr25505

[Andrew MacLeod]

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

Andrew