https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
;; ??? For !flag_finite_math_only, the representation with SMIN/SMAX
;; isn't really correct, as those rtl operators aren't defined when
;; applied to NaNs. Hopefully the optimizers won't get too smart on us.
(define_expand "<code><mode>3<mask_name><round_saeonly_name>"
[(set (match_operand:VF 0 "register_operand")
(smaxmin:VF
(match_operand:VF 1 "<round_saeonly_nimm_predicate>")
(match_operand:VF 2 "<round_saeonly_nimm_predicate>")))]
"TARGET_SSE && <mask_mode512bit_condition> &&
<round_saeonly_mode512bit_condition>"
{
if (!flag_finite_math_only)
operands[1] = force_reg (<MODE>mode, operands[1]);
ix86_fixup_binary_operands_no_copy (<CODE>, <MODE>mode, operands);
})
and
;; These versions of the min/max patterns implement exactly the operations
;; min = (op1 < op2 ? op1 : op2)
;; max = (!(op1 < op2) ? op1 : op2)
;; Their operands are not commutative, and thus they may be used in the
;; presence of -0.0 and NaN.
(define_insn "*ieee_smin<mode>3"
[(set (match_operand:VF 0 "register_operand" "=v,v")
(unspec:VF
[(match_operand:VF 1 "register_operand" "0,v")
(match_operand:VF 2 "nonimmediate_operand" "vm,vm")]
UNSPEC_IEEE_MIN))]
"TARGET_SSE"
...
maybe explain the -O2 code. Note that the middle-end uses min/max
regardless of flags and makes it the targets responsibility to disable
instructions that don't conform to IEEE.
The above suggests that a>b ? a : b isn't IEEE conform on x86.
