Re: [RFC] Do pointer comparison first in operand_equal_p

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 13 May 2005, Diego Novillo wrote:
> Both OEP_CONST_ONLY and OEP_PURE_SAME ought to not have
> side-effects, right?  The only thing that was pointed out that
> may give different behaviour is ERROR_MARK, but that can be fixed
> by making ERROR_MARK have side-effects (if it doesn't already).

No.  The same VAR_DECL (i.e. with pointer equality) is not
considered equal with OEP_CONST_ONLY.  At different points in
the same program, that VAR_DECL may contain different values.
Hence, the use of OEP_CONST_ONLY control whether the equality
is considered instantaneous, or per translation unit.

Likewise, OEP_PURE_SAME is testing whether a call to a pure
function will return the same result.  If there has been a
write to memory between the two, then the result will be false,
even though the pure function itself has no side-effects.

As you can see, the tree-ssa optimizers should use flags=0 to
compare operands within a single SSA statement, but flags=OEP_CONST_ONLY
to compare operands from two different SSA statements.  The middle-case,
flags=OEP_PURE_SAME can be used when there has been no write to memory
between the two SSA statements.

I hope this explains things.


> Hmm, I'm looking at the problem as a customer of fold-const.c,
> not a provider :)

These flags were added by the tree-ssa folks to capture the semantics
that were required by different requirements of the SSA passes.



> If you don't think this is a safe change, would you be willing to
> provide this minor speedup I obtained in some other way?

As I said before, splitting up operand_equal_p into separate functions
so that tree-ssa can call the correct one, will allow the most common
usage to benefit from your "arg0 == arg1" speed-up.



> > As written your patch may break stuff.
> >
> OK, though I'm not interested in guessing what it may break.
> Have a test case in mind?

It was Jeff that added these flags.  If you do a grep for where
OEP_CONST_ONLY is explicitly passed, it might provide a clue as
to why it is needed.

My first reaction when Jeff thought your change was OK was to
grep the source tree to see if OEP_CONST_ONLY was no longer
used.  Unfortunately, it is still being used, but I'm not sure
if those usages are still required.  Your testing seems to
indicate that they aren't currently tested and probably aren't
critical.

The use of SSA_NAME in tree-ssa may have obviated the VAR_DECL
example above.  But I'd have though that CSE hash-table lookup
or the new reassociation pass would be using operand_equal_p on
expressions from different statements.


Let me know if you interpret the commentary about operand_equal_p
or its current implementation differently.  For example, you'll
notice the existing "arg0 == arg1" test already in operand_equal_p
is further down, and much more qualified that the test you're proposing
to replace it with.

I hope this helps.

Roger
--