On Fri, Jan 31, 2025 at 08:04:53AM +0100, Richard Biener wrote:
> I fail to see where -Ofast is allowed, but only see the pre-existing
> flag check above
> which checks for no NaN/Inf rather than sNaN - the latter would be checked
> with
> HONOR_SNANS (mode).
Well -Ofast sets the flag_finite_math option to 0.
> I guess you really want
>
> > || code == UNLT || code == UNLE || code == UNGT || code == UNGE
> > || code == UNEQ || code == LTGT))
> > - return reverse_condition_maybe_unordered (code);
> > + return (no_ordered
>
> return (no_ordered && HONOR_SNANS (mode)
>
> no?
No. That won't work. Mode is CCFP, not one of the floating point modes. At
the point the test is done, you don't have the original floating point mode.
The code looks like:
(insn 10 6 11 2 (set (reg:CCFP 122)
(compare:CCFP (reg:DF 128 [ a ])
(reg:DF 129 [ b ]))) "pr118541.c":23:41 317 {*cmpdf_fpr}
(expr_list:REG_DEAD (reg:DF 129 [ b ])
(expr_list:REG_DEAD (reg:DF 128 [ a ])
(nil))))
(jump_insn 11 10 12 2 (set (pc)
(if_then_else (unle (reg:CCFP 122)
(const_int 0 [0]))
(label_ref 13)
(pc))) "pr118541.c":23:41 890 {*cbranch}
(expr_list:REG_DEAD (reg:CCFP 122)
(int_list:REG_BR_PROB 536870916 (nil)))
Ifcvt is looking at jump, trying to convert it into a cmove.
Also with the user explicitly using isgreater and friends (which is the only
way you get UNLE, etc. comparisons), I would prefer not to have the user
explicityly use '-fsignaling-nans' just to get code that does not trap. For
normal code, sure I can see possibly not doing any thing extra for SNANs unless
they use -fsignaling-nans, but if the user explicitly uses isgreater which says
it does not trap, we should generate code that will trap in some case.
Normal code using '>', etc. will only generate GT, GE, etc. and it will
generate the cmove.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
