llvm-reduce: Add broken testcase that shows uselistorder problem

[arsenm]

Summary

I've been trying to track down this problem for a while and finally
found a small enough reproducer for a test. Reductions sometimes
produce text IR which does not parse, with errors such as

"error: wrong number of indexes, expected 9"

This appears to not happen with bitcode reduction, as the bitcode
reader seems to silently discard uselistorder when the sizes don't
match. I believe this is caused by dangling constants in the
LLVMContext, which is currently recycled between different reductions.

[aeubanks]

I think I ran into this once and just disabled uselistorder printing

the proper fix is to disallow inspecting uses of constants so we can stop printing the uselistorder for constants. I looked into this before but there were some passes doing weird things (func-spec I think?) and I never got around to fixing things

separately we could use different LLVMContexts?

[arsenm]

In D154203#4464450, @aeubanks wrote:

separately we could use different LLVMContexts?

That's what I was looking into. There's also the related problem tracked by reduce-functions-blockaddress-wrong-function.ll (that one at least seems to be fixed by just always using the parallel reduction path)

[arsenm]

In D154203#4464450, @aeubanks wrote:

I think I ran into this once and just disabled uselistorder printing

the proper fix is to disallow inspecting uses of constants so we can stop printing the uselistorder for constants. I looked into this before but there were some passes doing weird things (func-spec I think?) and I never got around to fixing things

I've also seen this happen with global addresses, where the use list order more obviously matters

[arsenm]

ping, I don't know when I'm going to get back to looking at this and want to ensure the test isn't lost

[regehr]

yes, please add this, thanks!

[aeubanks]

seems fine to check in especially to verify if we ever fix it, one nit

llvm/test/tools/llvm-reduce/uselistorder-invalid-ir-output.ll

51

this CHECK line seems fragile, perhaps just uselistorder i32 0, {, and rely on the not llvm-as line check that it's invalid

[arsenm]

llvm/test/tools/llvm-reduce/uselistorder-invalid-ir-output.ll

51

Given the point is to express that this is broken, I think this is OK. Anything that perturbs this should require attention

[arsenm]

11ad5401187761e7b4a4315b38125188037b60e8

llvm/test/tools/llvm-reduce/Inputs/llvm-as-and-filecheck.py

+"""
+Script to assemble a text IR file and run FileCheck on the output with the
+provided arguments. The first 2 arguments are the paths to the llvm-as and
+FileCheck binaries, followed by arguments to be passed to FileCheck. The last
+argument is the text IR file to disassemble.
+
+Usage:
+    python llvm-as-and-filecheck.py
+      <path to llvm-as> <path to FileCheck>
+      [arguments passed to FileCheck] <path to text IR file>
+
+"""
+import sys
+import os
+import subprocess
+
+llvm_as = sys.argv[1]
+filecheck = sys.argv[2]
+filecheck_args = [
+    filecheck
+]
+
+filecheck_args.extend(sys.argv[3:-1])
+ir_file = sys.argv[-1]
+bitcode_file = ir_file + ".bc"
+
+# Verify the IR actually parses since FileCheck is too dumb to know.
+assemble = subprocess.Popen([llvm_as, "-o", bitcode_file, ir_file])
+assemble.communicate()
+
+if assemble.returncode != 0:
+    print("stderr:")
+    print(assemble.stderr)
+    print("stdout:")
+    print(assemble.stdout)
+    sys.exit(0)
+
+filecheck_args.append("--input-file")
+filecheck_args.append(ir_file)
+
+check = subprocess.Popen(filecheck_args)
+check.communicate()
+sys.exit(check.returncode)

llvm/test/tools/llvm-reduce/uselistorder-invalid-ir-output.ll

+; RUN: llvm-reduce -j=1 --abort-on-invalid-reduction \
+; RUN:   --delta-passes=operands-zero \
+; RUN:   -o %t.reduced.ll %s \
+; RUN:   --test=%python --test-arg %p/Inputs/llvm-as-and-filecheck.py \
+; RUN:   --test-arg llvm-as \
+; RUN:   --test-arg FileCheck --test-arg --check-prefix=INTERESTING \
+; RUN:   --test-arg %s
+
+; Check if the final output really parses
+; RUN: not llvm-as -o /dev/null %t.reduced.ll
+; RUN: FileCheck --check-prefix=RESULT %s < %t.reduced.ll
+
+
+define void @kernel_ocl_path_trace_direct_lighting(i1 %cond.i, i1 %cmp5.i.i, i32 %arg) {
+; INTERESTING: entry:
+; INTERESTING: 0
+; INTERESTING: 0
+; INTERESTING: %cmp5.i.i2 = icmp slt i32 {{[0-9]+}}, 0
+entry:
+  %add_zero_a = add i32 %arg, 0
+  %load1.i1 = load i32, ptr addrspace(1) null, align 4
+  %add_zero_b = add i32 %arg, 0
+  %cmp5.i.i2 = icmp slt i32 1, 0
+  br i1 %cond.i, label %if.end13.i.i, label %if.then6.i.i
+
+; INTERESTING: if.then6.i.i:
+; INTERESTING: %cond.i4 = icmp eq i32 %load0.i, 0
+if.then6.i.i:
+  %load0.i = load i32, ptr addrspace(4) null, align 4
+  %cond.i4 = icmp eq i32 %load0.i, 0
+  %extractVec358.i.i = insertelement <4 x float> zeroinitializer, float 1.000000e+00, i64 0
+  br i1 %cmp5.i.i, label %if.end13.i.i, label %kernel_direct_lighting.exit
+
+if.end13.i.i:
+  br i1 false, label %if.then263.i.i, label %if.end273.i.i
+
+; INTERESTING: if.then263.i.i:
+; INTERESTING-NEXT: i32 0
+if.then263.i.i:
+  %extractVec72.i.i.i11 = shufflevector <3 x float> zeroinitializer, <3 x float> zeroinitializer, <4 x i32> <i32 0, i32 1, i32 2, i32 poison>
+  br i1 %cond.i, label %if.end273.i.i, label %kernel_direct_lighting.exit
+
+; INTERESTING: if.end273.i.i:
+if.end273.i.i:
+  br label %kernel_direct_lighting.exit
+
+kernel_direct_lighting.exit:
+  ret void
+}
+
+; RESULT: uselistorder i32 0, { 4, 0, 5, 1, 6, 2, 7, 3 }