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

[Eli Bendersky]

On Wed, Apr 10, 2013 at 6:33 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Apr 10, 2013, at 2:31 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> > At the risk of being off-topic: It would be really nice to be able to
> write regression tests that don't depend on the order chosen by the
> instruction scheduler. I think that, for that, it would be useful to be
> able to define groups of check lines for which the order does not matter.
> Maybe something like this:
> >
> > ; CHECK-GROUP-BEGIN
> > ; CHECK: add [[REG1:r[0-9]+]], r1, r2
> > ; CHECK: add [[REG2:r[0-9]+]], r3, r4
> > ; CHECK: mul [[REG1]], [[REG2]]
> > ; CHECK-GROUP-END
> >
> > The first two add instructions are independent, and I don't care in
> which order they appear. The dependence of the mul on the adds is still
> captured by the named regex patterns. FileCheck could check all patterns in
> the group at each line, removing those that have matched from consideration.
> >
> > What do you think?
>
> I think that would be great! It is particularly important now that we are
> adding new scheduling models and a whole new MI scheduler is about to be
> enabled. Test cases should express the invariant they care about, not some
> nebulous 'stability' property.
>
> 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?

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