<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 11, 2013, at 7:26 AM, Eli Bendersky <<a href="mailto:eliben@google.com">eliben@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">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 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; position: static; z-index: auto; "><div class="im">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 style="">Jakob, can you elaborate on the semantics of the CHECK-DAG construct? </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>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><div><br></div><div>/jakob</div><div><br></div></div></body></html>