https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #15) > (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. If this is the case, then all cases of IEEE_MAXMIN UNSPECs should be implemented as you suggested. A better insn name brings extra points! ;)
