https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #14) > (In reply to Jakub Jelinek from comment #13) > > Though, unsure about why ieee is used in the name of some of the patterns, > > my copy of IEEE says that minNum and maxNum should return the non-NaN > > operand if one is NaN and other is not, and unspecified which one is > > returned when both are 0s of any sign or both are NaNs. > > The VMINSS etc. definition clearly is src1 < src2 ? src1 : src2 and that can > > be represented in RTL as (if_then_else (unge (match_operand 1) > > (match_operand 2)) (match_dup 2) (match_dup 1)) or so, no need for UNSPEC. > > Or am I missing something? > Please note that in the test the insn is generated from the intrinsic, which > has documented behaviour wrt zeros and NaNs [1]. The testcase expects this > behaviour and this is why we should emit UNSPEC. We can still emit smin/smax > RTX if NaNs and signed zeros can be ignored. What I meant is that the above mentioned IF_THEN_ELSE could represent exactly the behavior the insn has (i.e. use src2 for unordered or equal or greater, no exceptions for qNaN) and has the advantage of being constant foldable if both operands are constants. Both for the scalar and vector cases.
