[llvm-bugs] [Bug 31671] New: [Loop vectorizer] Run-time failures in test-suite with AVX512F

[via llvm-bugs]

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

            Bug ID: 31671
           Summary: [Loop vectorizer] Run-time failures in test-suite with
                    AVX512F
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: elad2.cohen at intel.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 17849
  --> https://llvm.org/bugs/attachment.cgi?id=17849&action=edit
test compiled with TOT clang -marh=knl -S -emit-llvm

The tests:

test-suite MultiSource/Benchmarks/TSVC/LoopRerolling-dbl/LoopRerolling-dbl
test-suite MultiSource/Benchmarks/TSVC/LoopRerolling-flt/LoopRerolling-flt

fail in runtime (wrong output) when built with AVX512 (and executed on KNL
target) - specifically the function s351() returns a wrong result.

Initially, it seems that is started failing due to the combination of r290810
and r284779. But these are actually just changes to the cost model and enabling
interleaved memory accesses by default for X86. Bisecting the erroneous
function while compiling with `force-vector-width` and
`enable-interleaved-mem-accesses` seems to lead to r282418.

I've attached the .ll files produced by compiling with -march=knl using TOT
clang VS TOT+revert-r282418.

The C code that contains the diff in IR is:
int s351() {
...
     TYPE alpha = c[0];
     for (int nl = 0; nl < 8*ntimes; nl++) {
         for (int i = 0; i < LEN; i += 5) {
             a[i] += alpha * b[i];
             a[i + 1] += alpha * b[i + 1];
             a[i + 2] += alpha * b[i + 2];
             a[i + 3] += alpha * b[i + 3];
             a[i + 4] += alpha * b[i + 4];
         }
         dummy(a, b, c, d, e, aa, bb, cc, 0.);
     }
..
     check(1);
     return 0;
 }

Putting aside the fact the the loop wasn't re-rolled, from the diff it looks
like the generated IR is doing something wrong(See that attached files for a
full context):

TOT:
  %10 = add <16 x i64> %broadcast.splat, <i64 1, i64 6, i64 11, i64 16, i64 21,
i64 26, i64 31, i64 36, i64 41, i64 46, i64 51, i64 56, i64 61, i64 66, i64 71,
i64 76>
...
  %VectorGep86 = getelementptr inbounds %struct.GlobalData, %struct.GlobalData*
@global_data, i64 0, i32 0, <16 x i64> %10
  call void @llvm.masked.scatter.v16f32(<16 x float> %15, <16 x float*>
%VectorGep86

TOT+revert:
  %10 = or i64 %offset.idx, 1
  %broadcast.splatinsert86 = insertelement <16 x i64> undef, i64 %10, i32 0
  %broadcast.splat87 = shufflevector <16 x i64> %broadcast.splatinsert86, <16 x
i64> undef, <16 x i32> zeroinitializer
...
  %VectorGep88 = getelementptr inbounds %struct.GlobalData, %struct.GlobalData*
@global_data, i64 0, i32 0, <16 x i64> %broadcast.splat87
  call void @llvm.masked.scatter.v16f32(<16 x float> %14, <16 x float*>
%VectorGep88

In the latter it seems that the scatter writes to a splat of the i+1 instead of
<i+1,i+6,i+11,..,i+76>

-- 
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/20170117/9f0a0589/attachment.html>