<div dir="ltr">Looks good to me - please commit<br><br>A few thoughts:<br><br>* <span style="color:rgb(0,0,0);font-family:'Courier New',Courier,monospace;font-size:14px;white-space:pre-wrap">low-pc-cu.ll creates temporary files, rather than piping the llc output straight to dwarfdump - if you want to cleanup the existing use to pipe directly, and make your new use do the same, that'd be nice (can be done in the same commit, or cleanup first then following the newer convention with your main commit)

* if FileCheck requires a CHECKPREFIX before a CHECKPREFIX-NEXT, that seems like a bug to me (but I could be wrong) - it seems perfectly reasonable (as in your case) that we might have a CHECK1 using one prefix, then a CHECK2-NEXT using a different 
prefix. If you're curious, perhaps you could look into fixing the FileCheck bug there? But it's not important in this case, because... 

* to make tests more resilient to attribute ordering changes, I usually avoid using CHECK-NEXT, instead I put a CHECK-NOT: DW_TAG between a tag and its attribute and between each attribute - that way other attributes can appear and they don't break the test, but we don't accidentally end up checking the attributes of some other tag. (and I use CHECK-NOT: {{DW_TAG|NULL}} between one tag and the next to make sure there's no extra tags in between (especially important if they change the parenting relationship - eg: if I want to find a child of this tag, I don't necessarily want to succeed if the node I'm looking for is a grandchild rather than a direct child))</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 1:39 PM, Frédéric Riss <span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span> wrote:<br><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><blockquote type="cite"><div class=""><div>On 28 Aug 2014, at 20:13, Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>> wrote:</div></div>
<div><div style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class=""><blockquote type="cite"><div><br>On 28 Aug 2014, at 20:01, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><div><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><br></div></div></div></div></blockquote></div><div class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do we have existing test coverage for the subprogram case? I imagine we do somewhere (try breaking it and see which tests fail) though it might not be a nice/tidy as your test case. Perhaps you could add the CU coverage to the same test case (& possibly clean it up a bit if it's not as legible as your new case)<br>
</div></div></div></div></div></blockquote><div><br></div><div>I can try to do that.</div></div></div></div></blockquote><br></div><div>Here is a new patch piggybacking the testing onto 2 existing tests. This way we verify compile_unit, subprogram and lexical_scope encodings.</div>
<div><br></div><div>In the lexical scope test, I dropped the -NEXT constraint on the pattern as it would require duplicating the whole CHECK patterns (a CHECK-V4-NEXT needs a previous CHECK-V4). I wasn’t sure which way is better, I can of course keep all the -NEXT constraints and duplicate the whole pattern 2 times.</div>
<div><br></div><div>Fred</div><div></div></div><br><div style="word-wrap:break-word"><div></div></div><br></blockquote></div><br></div>