Re: [PATCH] Fix 20020720-1.c on MIPS

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 14 Oct 2002, Richard Henderson wrote:
> > Is this a sufficient answer?  Are there any other tests we could try?
> > I'd normally argue that if there was a problem of this type it'd be
> > picked up by a GCC bootstrap, but I suspect neither the compiler
> > nor its testsuite test would help in finding a NaN comparison issue.
>
> Dunno.  To be sure, what are the two patterns on mips that
> are getting combined with this patch, but not before?

The relevant four patterns are:


(insn 10 (set (reg/v:DF 182 (abs:DF (reg/v:DF 181)))))

(insn 12 (set (reg/v:DF 183 (const_double:DF 0.0))))

(insn 14 (set (reg:CC 67 $fcc0 (lt:CC (reg/v:DF 182) (reg/v:DF 183)))))

(insn 15 (set (pc) (if_then_else (eq:CC (reg:CC 67 $fcc0) (const_int 0))
                                 (label_ref 25) (pc))))


Combine is combining/simplifying the first three insns, which it
manages to reduce to a single pattern

(set (reg:CC 67 $fcc0 (const_int 0)))

Unfortunately, this pattern isn't recognized by the MIPS backend.
The fix for PA-RISC by Dave Anglin was to add support for this
pattern, but unfortunately my attempts to set the appropriate
bits in %fpsr as a pattern in mips.md proved beyond my abilities.

My solution is to use the cc0 forth-instruction look ahead that
checks if the condition code register has a single user, and
tries combining the condition code result with its use.  Many
cc0 targets don't have explicit condition code setting patterns.
In the example above, the single use, a conditional jump, gets
simplified to an unconditional jump, (set (pc) (label_ref 25)).

On machines where condition codes are stored in cc0, or
insn 14 computes its result as a COMPARE rtx things work fine.
This patch just extends these cases to also handle CC_MODE
regs.

Roger
--