Re: ifcvt: cond_exec-like behavior on cc0 machines

[Richard Henderson <rth at redhat dot com>]

On Mon, Jul 21, 2003 at 06:44:21PM -0300, Alexandre Oliva wrote:
> The reason is the init_propagate_block() block of code conditioned by
> HAVE_conditional_execution.  Ports that use cc0 in conditions for
> branches will crash here:
> 
> 	  if (GET_CODE (reg) != REG)
> 	    abort ();
> 
> because reg is cc0.

(1) This seems easy enough to fix.

> Even if I try to canonicalize cond_true with
> get_condition, to know the actual condition the branch is subject to,
> it may still fail.  get_condition won't always be able to find the
> condition, if cc0 is set by side effect by a previous instruction
> (something that splitters, peepholes or maybe even expanders might
> introduce), it fails, and then the conditional life tracking code
> fails even earlier.

(2) This is false.  The cc0 setter must *must* MUST be the previous
instruction.  Until final, which interprets NOTICE_UPDATE_CC, the
previous instruction absolutely must explicitly mention cc0 (usually
a comparison insn).  Anything else is a bug.  No searching required.

So if you saw anything else with splitters, expanders, or peepholes,
then one of them is broken.

I really REALLY don't see the difference between

	(cond_exec (eq (cc0) (const_int 0))
	  (set (reg X) (or (reg Y) (reg Z))))

and

	(set (reg X)
	     (if_then_else (eq (cc0) (const_int 0))
		(or (reg Y) (reg Z))
		(reg X)))

>From the point of view of flow, both *ought* to work.

But I'm as yet unconvinced that ifcvt needs to add support for the
later if its effectively identical to the former.


r~