Re: PATCH COMMITTED: Use conditional moves in groups of assignments

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 31 Jan 2006, Richard Earnshaw wrote:
> On Tue, 2006-01-31 at 16:43, Hans-Peter Nilsson wrote:
> > Defined *where*?
>
> By the entire implementation of reload (OK, I don't think it's mentioned
> in rtl.texi, but then many things aren't...).

Uh, that sounds a lot like the "feature" (complete with flaws,
bugs and illogical consequences) that predicates matching unary
operators cause their constraints to be evaluated for the unop
arguments...  (That hasn't changed yet and I don't think it'll
do in time for 4.2.  Proof-of-concept patch sent to fix sh64,
but it had a few bugs and it sounded like sh64 was about to be
fixed as part of an overhaul anyway, so no update.)
I'm digressing.

>  This was discussed long
> ago before we introduced cond_exec: it was the entire reason for
> introducing a new code.
>
> Consider the following RTL:
[elided]

I understood that was what you referred to in your first reply
and that any other interpretation would require special-casing
it in reload and that it has the potential to be ...nasty,
probably introducing program flow changes in reload.

> > I don't see this pecularity mentioned in e.g.
> > rtl.texi, md.texi or rtl.def.  It'd be quite important to
> > document (not just as stray comments).
>
> Fancy writing the patch?

Nope, partly because I don't like it.  I'm undecided, but I
might actually prefer reload to be special-cased for
if_then_else constructs with side-effects in reloaded arms.
I understand that as this was discussed "long ago" (in the dark
ages of gcc2@vger, I guess), I'm a bit too late to the game.  I
have no immediate use for either definition myself though, so
I'm not going to write either patch, for a foreseeable future.
:-}

Since you're armed with both history and logical arguments, I
suggest you yourself update the documentation to match your
argumentation and a reality I understand you helped implement.

brgds, H-P