Re: [PATCH] Fix part of pr25505

[Josh Conner <jconner at apple dot com>]

Andrew MacLeod wrote:
> 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.

It would be nice to commit my original change, since it's a strict
improvement that (partly) fixes a regression.  Can I get approval on
that for mainline, unless there are objections?  Note that there has
been no discussion of the tree-gimple portion of this, so I'm not sure
it has even been considered.

I'd be glad to look into fixing the tree-nrv code in question, but I
would need some help understanding how to get something other than a
VAR_DECL on the LHS in order to actually verify behavior.  Anyone?

- Josh