<div dir="ltr">On Wed, Apr 10, 2013 at 2:31 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>

<br>
; CHECK-GROUP-BEGIN<br>
; CHECK: add [[REG1:r[0-9]+]], r1, r2<br>
; CHECK: add [[REG2:r[0-9]+]], r3, r4<br>
; CHECK: mul [[REG1]], [[REG2]]<br>
; CHECK-GROUP-END<br>
<br>
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.<br>

<br>
What do you think?<br></blockquote><div><br></div><div style>This has been rehashed repeatedly on the lists. If you want to re-open those discussions, cite the history and what new information is motivating it.</div><div style>
<br></div><div style>For folks who missed the discussion, I (and others) have pushed back against this because fundamentally the output of the compiler should be deterministic and stable, even if arbitrary. So encoding a particular arbitrary ordering, while annoying when updating, hasn't historically been a huge burden. It might be a huge burden if it occurs in a very large number of places causing very large churn on innocent changes, but so far it has only come up in a small enough number of places to not be a huge issue. (Register names on the other hand when hard coded did become such a burden, and we've moved to consistently not hard code registers where doing so doesn't make sense.)</div>
<div style><br></div><div style><br></div><div style>I actually wonder whether the above rationale applies to Reid's situation as well. I'd like to better understand why writing a particular output creates a maintenance problem.</div>
<div style><br></div><div style><br></div><div style>Regarding the "-NOT" version, I don't really see the need as the -NOT ones are essentially order independent amongst themselves, and only ordered w.r.t. the positive assertions...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again,<br>
Hal<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
> From: "Reid Kleckner" <<a href="mailto:rnk@google.com" class="cremed">rnk@google.com</a>><br>
> To: "Eli Bendersky" <<a href="mailto:eliben@google.com" class="cremed">eliben@google.com</a>><br>
> Cc: "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a>><br>
> Sent: Wednesday, April 10, 2013 4:20:40 PM<br>
> Subject: Re: [PATCH] Add support to FileCheck for out-of-order matching<br>
><br>
> I was thinking more like this could succeed:<br>
> ; CHECK: foo<br>
> ; CHECK-ANYWHERE: bar<br>
> ; CHECK-NEXT: baz<br>
><br>
> bar <- second<br>
> baz <- third<br>
> foo  <- first match<br>
><br>
> The goal being to handle something like the vtable layout tests,<br>
> which<br>
> would look like:<br>
><br>
> // RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm-only<br>
> -fdump-vtable-layouts |& FileCheck %s<br>
> ...<br>
> namespace Test1 {<br>
> // CHECK-ANYWHERE:      Vtable for 'Test1::A' (3 entries).<br>
> // CHECK-NEXT:   0 | offset_to_top (0)<br>
> // CHECK-NEXT:   1 | Test1::A RTTI<br>
> // CHECK-NEXT:       -- (Test1::A, 0) vtable address --<br>
> // CHECK-NEXT:   2 | void Test1::A::f()<br>
> struct A {<br>
>   virtual void f();<br>
> };<br>
> void A::f() { }<br>
> }<br>
><br>
> Instead of the current repeated FileChecks with prefixes:<br>
><br>
> // RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm-only<br>
> -fdump-vtable-layouts > %t 2>&1<br>
> // RUN: FileCheck --check-prefix=CHECK-1 %s < %t<br>
> // RUN: FileCheck --check-prefix=CHECK-2 %s < %t<br>
> ...<br>
> // CHECK-1:      Vtable for 'Test1::A' (3 entries).<br>
> // CHECK-1-NEXT:   0 | offset_to_top (0)<br>
> // CHECK-1-NEXT:   1 | Test1::A RTTI<br>
> // CHECK-1-NEXT:       -- (Test1::A, 0) vtable address --<br>
> // CHECK-1-NEXT:   2 | void Test1::A::f()<br>
><br>
> On Wed, Apr 10, 2013 at 5:01 PM, Eli Bendersky <<a href="mailto:eliben@google.com" class="cremed">eliben@google.com</a>><br>
> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Apr 10, 2013 at 2:00 PM, Eli Bendersky <<a href="mailto:eliben@google.com" class="cremed">eliben@google.com</a>><br>
> > wrote:<br>
> >><br>
> >> On Wed, Apr 10, 2013 at 1:40 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="cremed">rnk@google.com</a>><br>
> >> wrote:<br>
> >>><br>
> >>> It seems like we have a bunch of tests where we really don't care<br>
> >>> about ordering.  Should we add support to FileCheck for that?<br>
> >>><br>
> >>> For example, this test uses repeated filecheck runs on the temp<br>
> >>> file<br>
> >>> output with different prefixes just to work around this problem:<br>
> >>><br>
> >>> <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vtable-layout.cpp?view=markup" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vtable-layout.cpp?view=markup</a><br>

> >>> I had the same problem while working on vbtable layout.<br>
> >>><br>
> >>> This is a big grep test that can't easily be filecheck-ified<br>
> >>> because<br>
> >>> there's no out of order matching:<br>
> >>><br>
> >>> <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/metadata-symbols-64.m?revision=174461&view=markup" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/metadata-symbols-64.m?revision=174461&view=markup</a><br>

> >>> I'd like to filecheck-ify that test because there's something<br>
> >>> wrong<br>
> >>> with the grep escaping on my system.<br>
> >>><br>
> >>> I propose CHECK-ANYWHERE, or something else with the same<br>
> >>> behavior.<br>
> >>> Basically, this is a check directive that just resets the<br>
> >>> matching<br>
> >>> cursor back the beginning of the file.  Any subsequent checks<br>
> >>> follow<br>
> >>> from the end of a successful match.  Any captured variables are<br>
> >>> preserved, mostly because removing them would be hard.<br>
> >><br>
> >><br>
> >> The proposal is interesting, but I have doubts about the proposed<br>
> >> implementation. Wouldn't this make the semantics of some tests<br>
> >> very...<br>
> >> unusual? Consider this:<br>
> >><br>
> >> CHECK: foo<br>
> >> CHECK-EVERYWHERE: bar<br>
> >> CHECK: baz<br>
> >><br>
> >> Is this going to match:<br>
> >><br>
> >> baz<br>
> >> foo<br>
> >> bar<br>
> >><br>
> >> That's kind-of weird :-)<br>
> ><br>
> ><br>
> > I figured I should be more constructive :-)<br>
> > An alternative proposal without this problem (AFAICS) is to collect<br>
> > all<br>
> > "-EVERYWHERE" checks and run them separately in the end on the<br>
> > whole file.<br>
> > They're order-independent, so this seems safe. And oh while we're<br>
> > at it,<br>
> > let's call it CHECK-GLOBAL and also have CHECK-GLOBAL-NOT because<br>
> > that one<br>
> > would be really useful for rewriting some 'not grep' tests.<br>
> ><br>
> > Eli<br>
> ><br>
> ><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>