<div dir="ltr">On Thu, Apr 11, 2013 at 9:00 AM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</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"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Apr 11, 2013, at 7:26 AM, Eli Bendersky <<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>> wrote:</div>
<br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="im">On Wed, Apr 10, 2013 at 6:33 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br>
</div><div class="im"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>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:</div>


<br>
; CHECK: testfunctionname<br>
; CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2<br>
; CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4<br>
; CHECK-DAG: mul [[REG1]], [[REG2]]<br>
; CHECK: ret<br>
<br>
This would make CHECK-DAG and CHECK-NOT work the same, except you can't define variables in a CHECK-NOT, of course.<br></blockquote><div><br></div><div>Jakob, can you elaborate on the semantics of the CHECK-DAG construct? </div>
</div></div></div></div></blockquote><div><br></div><div>With line numbers:</div><div><br></div><div>1: CHECK: testfunctionname<br>2: CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2<br>3: CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4<br>
4: CHECK-DAG: mul [[REG1]], [[REG2]]<br>5: CHECK: ret<br></div><div><br></div><div>Just like CHECK-NOT, FileCheck will skip CHECK-DAG on the first pass, so it initially matches the anchors in line 1 and 5.</div><div><br></div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div></div></blockquote><div><br></div><div style>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.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>On second thought, that would make this invalid:</div><div>
<br></div><div>1: CHECK: testfunctionname<br>2: CHECK-DAG: add [[REG1:r[0-9]+]], r1, r2<br>3: CHECK-DAG: add [[REG2:r[0-9]+]], r3, r4<br>4: CHECK: mul [[REG1]], [[REG2]]<br></div><div><br></div><div>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.</div>
<div><br></div><div>[Currently, CHECK-NOTs can actually use variables defined by the anchor below them. I don't think we use that a lot.]</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div>
</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Eli</div><div> </div></div><br></div></div>