PATCH COMMITTED: Use conditional moves in groups of assignments

[Richard Earnshaw]

On Sun, 2006-01-29 at 08:30, Hans-Peter Nilsson wrote:
> On Wed, 18 Jan 2006, Richard Earnshaw wrote:
> > Note we have two conditional forms in RTL: cond_exec and if_then_else.
> >
> > COND_EXEC is uses when all side effects are suppressed when the insn
> > fails its condition.  IF_THEN_ELSE is used for situations where the
> > side-effects are performed even if the value is not used.  So
> >
> > (cond_exec (ne: (pred) (const_int 0))
> > 	(set (r0) (mem (post_inc(addr)))))
> >
> > is very different from
> >
> > (set (r0) (if_then_else (ne (pred) (const_int 0))
> > 	(mem (post_inc (addr)))
> > 	(r0))
> >
> > Though the value stored in r0 is the same in both cases, the former will
> > not execute the memory access or increment addr if the condition fails,
> > the latter will do both of these.
> 
> That looks wrong: the false if_then_else arm isn't supposed to
> be executed *at all* i.e. not for side-effects like
> post-increment.  It's not logical; the false if_then_else arm of
> a conditional branch using if_then_else evaluated (usually just
> a label; but the address isn't evaluated for validity).
> Neither is it in similar common language constructs, like the C
> "cond ? x : y". construct.

It's not wrong.  Consider the case where the false arm needs reloads. 
The reloads are unconditionally executed.  if_then_else is defined in a
way such that only the final result is conditional, not the side
effects.  If you want an insn where *all* side-effects are suppressed,
use cond_exec, that's defined in such a way that side-effects of reloads
would also be cond-exec (though at present we never generate cond-exec
until after reload has been completed).

R.