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

[Eli Bendersky]

On Thu, Apr 11, 2013 at 9:00 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> 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.
>
>
Thanks for the explanation. I'm not sure about the -DAG name though; apart
from being overloaded in LLVM, it isn't intuitive for this use.


> 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.]
>
>
Yes, I agree this is confusing. In general, the semantics of mixing such
grouping with variable definitions are somewhat moot. If I read this
correctly, we can also have multiple valid matches depending on the order
the CHECK-DAG lines are searched.

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