Re: [PATCH] Fix part of pr25505

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2006-08-31 at 15:04 -0400, Daniel Berlin wrote:
> On 8/31/06, Andrew MacLeod <amacleod@redhat.com> wrote:
> > On Thu, 2006-08-31 at 14:48 -0400, Daniel Berlin wrote:
> > > > Ahh - got it.  So you're suggesting that I fix the previous logic, too.
> > > >  I was a bit hesitant because I wasn't clear on what the LHS could be
> > > > that wasn't a "simple decl", and so I didn't feel confident rewriting
> > > > this portion.
> > >
> > > Yeah, it is a bit confusing as to what FOR_EACH_SSA_DEF_OPERAND will
> > > hand you but, AFAIK, it will only hand you SSA_NAMES.
> > >
> >
> > It shouldn't be.  In valid, renamed, up-to-date stmt's,
> > FOR_EACH_SSA_*_OPERAND can *only* return SSA_NAMEs.  Non-ssa names can
> > only occur when the stmt is not up to date, or before ssa renaming has
> > taken place.
> >
> > The operand cache exists only to access SSA_NAMEs easily. You should
> > never get anything else in an up-to-date stmt.
> 
> And that's the problem. Quickly determining whether the piece of code
> you are dealing with deals with up-to-date statements is not always
> easy.
> So i can understand that bit of confusion.

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.

Andrew