[LLVMdev] teaching FileCheck to handle variations in order

[Pranav Bhandarkar]

> Can you explain why you were unable to add a small unit test to the testsuite?

This is the case I have.

******
       r3 = memb(r1+#1)
       r4 = memb(r1+ #0)
      ..
      ..
      {
        p0 = r3  /* Should almost never emit this. */
        p1 = r4  /* Should almost never emit this. */
     ..
    ..
       p0 = or(p1, p0)

*****
The CHECK tags I have are
; CHECK: [[IntReg0:r[0-9]+]] = memb     //IntReg0 is r3
; CHECK: [[IntReg1:r[0-9]+]] = memb    //IntReg1 is r4
; CHECK-NOT: {{r[0-9]+}} = zxtb([[IntReg1]])   //Ensure no zxtb instructions exist between the loads and their uses.
; CHECK-NOT: {{r[0-9]+}} = zxtb([[IntReg0]])
; CHECK: [[PredReg0:p[0-3]+]] = [[IntReg0]]  // <--- [1]
; CHECK: [[PredReg1:p[0-3]+]] = [[IntReg1]] // <---  [2]
; CHECK: or([[PredReg1]], [[PredReg0]])

When I was trying to write this testcase I had thought that if the order of [1] and [2] changed because of some change in the scheduler, the optimization (removal of zxtb) would still hold, but the changed order would cause a test failure.

I do understand your point about using such things as checks for non-determinism in the code generator, but I would argue that this should be best left to the judgement of the test case writer. 

Pranav
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation