Pranav Bhandarkar
2012-Sep-13 21:44 UTC
[LLVMdev] teaching FileCheck to handle variations in order
> 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
Chandler Carruth
2012-Sep-13 21:49 UTC
[LLVMdev] teaching FileCheck to handle variations in order
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>
Krzysztof Parzyszek
2012-Sep-14 16:15 UTC
[LLVMdev] teaching FileCheck to handle variations in order
On 9/13/2012 4:49 PM, Chandler Carruth wrote:> > 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.Why would they have to do that in the first place? Like I said, tests should not be checking things that they were not specifically meant to test. Hard time or not, I don't think anyone would be excited about having to go through a list of potential false positives. -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Reasonably Related Threads
- [LLVMdev] teaching FileCheck to handle variations in order
- [LLVMdev] teaching FileCheck to handle variations in order
- [LLVMdev] teaching FileCheck to handle variations in order
- [LLVMdev] teaching FileCheck to handle variations in order
- [LLVMdev] teaching FileCheck to handle variations in order