Newly added llvm-test-suite forced opt vectorizer tests have failure for RVV targets

[asb]

It's late here so this won't be the best report, just noting to avoid duplicated work.

In the last few hours additional vectorizer tests were added to llvm-test-suite. The following ones cause test failures (incorrect results at runtime, as opposed to a compile failure) for RVV targets:

  test-suite :: SingleSource/UnitTests/Vectorizer/tf-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tf-ftic-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tfactivelanemask-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tfactivelanemask-ftic-find-last.test

I don't think I can take further action until tomorrow morning UK time, but can look more closely then if nobody else has had a chance to poke at them.

I believe (but haven't yet confirmed definitively) these failed from the point they were added, i.e. are exposing an existing miscompile that wasn't tested before.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Alex Bradbury (asb)

Details

It's late here so this won't be the best report, just noting to avoid duplicated work.

In the last few hours additional vectorizer tests were added to llvm-test-suite. The following ones cause test failures (incorrect results at runtime, as opposed to a compile failure) for RVV targets:

  test-suite :: SingleSource/UnitTests/Vectorizer/tf-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tf-ftic-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tfactivelanemask-find-last.test
  test-suite :: SingleSource/UnitTests/Vectorizer/tfactivelanemask-ftic-find-last.test

I don't think I can take further action until tomorrow morning UK time, but can look more closely then if nobody else has had a chance to poke at them.

[asb]

I did get a chance to look a little bit. The newly added tests are uncovering an existing miscompile, but one only added a few days ago in #183911.

This is derived from the tf-find-last test:

target triple = "riscv64-unknown-linux-gnu"

@A = global [1000 x i16] zeroinitializer

define i16 @vector_fn(ptr %A, i16 %TC) {
entry:
  br label %for.cond

for.cond:
  %Rdx.0 = phi i16 [ 0, %entry ], [ %cond, %for.body ]
  %I.0 = phi i16 [ 0, %entry ], [ %add, %for.body ]
  %cmp = icmp slt i16 %I.0, %TC
  br i1 %cmp, label %for.body, label %for.end

for.body:
  %idxprom = sext i16 %I.0 to i64
  %arrayidx = getelementptr inbounds [1000 x i16], ptr %A, i64 0, i64 %idxprom
  %0 = load i16, ptr %arrayidx, align 2
  %cmp6 = icmp sgt i16 %0, 0
  %cond = select i1 %cmp6, i16 %Rdx.0, i16 %I.0
  %add = add i16 %I.0, 1
  br label %for.cond

for.end:
  ret i16 %Rdx.0
}

define i32 @main() {
entry:
  %call = call i16 @vector_fn(ptr @A, i16 1000)
  %cmp = icmp ne i16 %call, 999
  %ret = zext i1 %cmp to i32
  ret i32 %ret
}

Building this with:

./bin/clang++ --target=riscv64-linux-gnu --sysroot=$HOME/rvsysroot \
    -march=rva23u64 -std=gnu++17 -w \
    -mllvm -prefer-predicate-over-epilogue=predicate-dont-vectorize \
    -mllvm -force-tail-folding-style=data-without-lane-mask \
    -O3 repro.ll -o repro.out

The generated binary produces a different result before and after #183911. It looks like #191166 may be seeking to fix this.

[fhahn]

Good to see the added test coverage is actually useful

[lukel97]

Yeah those failures are to be expected, I wanted to reverse ping the PR that landed them since we were noticing the issue elsewhere in a separate PR. Hopefully the fix will land soon