[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.