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

[Jakob Stoklund Olesen]

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

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

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

I don't care what name we 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.

I don't think it is necessary to do anything other than a simple first-match. There is no need to get into graph theory.

I can fix the problem with having two passes:

CHECK-DAGs are matched on the first pass. They search the range from the previous anchor CHECK, or the last CHECK-DAG to define a variable they're using, whichever comes last. They search to the end of the file, like normal CHECKs.

A CHECK following a sequence of CHECK-DAGs starts searching from the last match in the sequence, which may not be the immediately preceding CHECK-DAG line since they match out of order. This means it will match text following all preceding CHECK-DAGs.

It's a bit tricky to define what CHECK-NOT does when mixed with CHECK-DAGs. It could be useful to give it the same range as a CHECK-DAG, except terminating at the next anchor CHECK as usual.

/jakob