[LLVMdev] teaching FileCheck to handle variations in order

Pranav Bhandarkar pranavb at codeaurora.org
Thu Sep 13 14:44:37 PDT 2012

> 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. 

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

More information about the llvm-dev mailing list