[LLVMdev] teaching FileCheck to handle variations in order

Chandler Carruth chandlerc at google.com
Thu Sep 13 14:49:50 PDT 2012


On Thu, Sep 13, 2012 at 2:44 PM, Pranav Bhandarkar
<pranavb at codeaurora.org>wrote:

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


I'm really not understanding what is wrong with adding this now, and adding
nice comments to it clarifying that these two things don't need to be in
any particular order, and are just used to bound the CHECK-NOT above.

I mean, it's inconvenient, mostly for the person changing the scheduler,
but provided there are helpful comments for them, I suspect they're not
going to have a hard time updating the test cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120913/678021e7/attachment.html>


More information about the llvm-dev mailing list