TREE_SIDE_EFFECTS vs STATEMENT_LIST vs recompute_side_effects

[Jeffrey A Law]

On Thu, 2004-06-24 at 11:52, Richard Henderson wrote:
> > That seems awfully wrong.  In gimple, COND_EXPRs shouldn't have any
> > side effects whatsoever.
> 
> Disagree.
Huh?  Really, what kind of side effects do you expect to see on
COND_EXPRs?


> Sure, but the GOTO_EXPRs that will replace the STATEMENT_LISTs
> *also* have side effects.  The side effect is a control transfer.
That's radically different from the docs for TREE_SIDE_EFFECTS:


/* In any expression, decl, or constant, nonzero means it has side
effects or
   reevaluation of the whole expression could produce a different value.
   This is set if any subexpression is a function call, a side effect or
a
   reference to a volatile variable.  In a ..._DECL, this is set only if
the
   declaration said `volatile'.  This will never be set for a constant. 
*/
#define TREE_SIDE_EFFECTS(NODE) \
  (NON_TYPE_CHECK (NODE)->common.side_effects_flag)


> The argument is true as a whole for the COND_EXPR both before and 
> after the lowering.
> 
> What is the deeper issue?
The deeper issue is in this case the bit propagates up through
the COND_EXPR, eventually to a COMPONENT_REF.

jeff