[tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c

[law@redhat.com]

In message <1055341485.824.47.camel@frodo.toronto.redhat.com>, Diego Novillo wr
ites:
 >On Wed, 2003-06-11 at 10:12, law@redhat.com wrote:
 >
 >> Doing these things exposes a latent but in how we set may_optimize_p for
 >> expresssions.  Namely we set it for expressions in which TREE_SIDE_EFFECTS
 >> is set.  tsk tsk.
 >> 
 >I thought that TREE_SIDE_EFFECTS should not be set on GIMPLE
 >expressions, with the exception of CALL_EXPRs.  Aren't you just papering
 >over a gimplification bug here?
No.  Consider VA_ARG_EXPR -- I've been unable to convince myself that
it's free of side effects.

Another example is volatile memory references.   The right way to detect
a volatile memory operation is from TREE_SIDE_EFFECTS.  Unfortunately, we
can't make that change right now because we use has_volatile_ops to avoid
looking at anything in static storage.  Sigh.

And consider if one day we do have some kind of tree node with a side
effect.  Better to catch it with a general mechanism like checking
TREE_SIDE_EFFECTS than having to special case more stuff.

And yes, this could potentially paper over a gimplification bug if 
the gimplifier left TREE_SIDE_EFFECTS set in an expression which had no
side effects.  Jason and I have in fact fixed a few of those kinds of
problems recently.

In fact, I was quite worried about that issue -- it doesn't affect
correctness, but it affects our quality of implementation in numerous
ways.  So I put in a few checks to see if we were leaving TREE_SIDE_EFFECTS
set in any unexpected ways.

[ Basically my test looks for TREE_SIDE_EFFECTS set on an expression that
  we would otherwise set may_optimize_p to true.  That's what uncovered the
  VA_ARG_EXPR case.  No others were triggered during a bootstrap of the
  compiler.  So while there may be some slipping through, I suspect they
  are pretty rare. ]

 >Also, don't we recognize functions whose calls can be elided if they're
 >called with the same arguments repeatedly?  (I forget the technical term
 >:)
Right now we do not remove redundant calls if they are pure.  That's
something I'll be looking at momentarily.  I'll note the old code 
didn't remove such calls either.

jeff