[PATCH] Add support to FileCheck for out-of-order matching

[Jakob Stoklund Olesen]

On Apr 11, 2013, at 7:26 AM, Eli Bendersky <eliben at google.com> wrote:

> On Wed, Apr 10, 2013 at 6:33 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
> I was coincidentally just about to propose something very similar, using the regex variables to encode DAG edges. I wouldn't add the GROUP-BEGIN and GROUP-END markers, though. I would simply use surrounding CHECK markers, the same as CHECK-NOT:
> 
> ; CHECK: testfunctionname
> ; CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2
> ; CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4
> ; CHECK-DAG: mul [[REG1]], [[REG2]]
> ; CHECK: ret
> 
> This would make CHECK-DAG and CHECK-NOT work the same, except you can't define variables in a CHECK-NOT, of course.
> 
> Jakob, can you elaborate on the semantics of the CHECK-DAG construct? 

With line numbers:

1: CHECK: testfunctionname
2: CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2
3: CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4
4: CHECK-DAG: mul [[REG1]], [[REG2]]
5: CHECK: ret

Just like CHECK-NOT, FileCheck will skip CHECK-DAG on the first pass, so it initially matches the anchors in line 1 and 5.

Then the CHECK-NOTs and CHECK-DAGs are checked in order. Line 2 is matched against the range between the line 1 and 5 anchor matches. Line 3 is matched against the same range, so those two lines can match out of order, or even match overlapping text.

Line 4 refers to the variables REG1 and REG2, so its search range is constrained to begin after both matches defining those variables. This means that CHECK-DAGs are forced to match in a topological order consistent with their variable dependencies.

On second thought, that would make this invalid:

1: CHECK: testfunctionname
2: CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2
3: CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4
4: CHECK: mul [[REG1]], [[REG2]]

The last anchor CHECK wouldn't be able to refer to variables defined by CHECK-DAGs preceding it. That seems confusing in a file with only positive tests.

[Currently, CHECK-NOTs can actually use variables defined by the anchor below them. I don't think we use that a lot.]

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130411/27e5b6a5/attachment.html>