[llvm-bugs] [Bug 36982] New: llvm.experimental.vector.reduce.{fmin, fmax} incorrect for vectors with NaN in the last place

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36982

            Bug ID: 36982
           Summary: llvm.experimental.vector.reduce.{fmin,fmax} incorrect
                    for vectors with NaN in the last place
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: llvm-bugs at lists.llvm.org

On x86_64:

define float @example::foo(<2 x float>* noalias nocapture readonly
dereferenceable(8) %x) unnamed_addr #0 {
  %0 = load <2 x float>, <2 x float>* %x, align 8
  %1 = tail call float @llvm.experimental.vector.reduce.fmin.f32.v2f32(<2 x
float> %0)
  ret float %1
}

lowers to:

example::foo:
  movq xmm0, qword ptr [rdi]
  pshufd xmm1, xmm0, 229
  minps xmm0, xmm1
  ret

which for the following inputs produces the respective outputs:

 * <1.0, -1.0> => -1.0
 * <NaN, -1.0> => -1.0
 * <-1.0, NaN> => NaN

I think this is basically equivalent to a vector fcmp + select, but the default
semantics of the reductions (that is, without math flags) should be that of
minnum/maxnum. 

The llvm.experimental.vector.reduce.fmin/fmax intrinsics do not specify their
semantics in the reference, so it is hard to tell whether the current behavior
is intended or an oversight.

This bug is Rust's bug: https://github.com/rust-lang-nursery/stdsimd/issues/408

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180403/5c1ec2d8/attachment-0001.html>