<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 15, 2017 at 7:46 AM Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Feb 14, 2017 at 7:55 PM, Teresa Johnson <span dir="ltr" class="gmail_msg"><<a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="m_8095805773368322678gmail-m_5490049026779165918gmail- gmail_msg">On Tue, Feb 14, 2017 at 2:36 PM, David Blaikie <span dir="ltr" class="gmail_msg"><<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br class="gmail_msg"></span><span class="m_8095805773368322678gmail-m_5490049026779165918gmail- gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg">I think this is probably the right thing (patch attached, and text here for readability):<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">diff --git lib/CodeGen/LexicalScopes.cpp lib/CodeGen/LexicalScopes.cpp</div><div class="gmail_msg">index fc84ddb1f6b..31203689b3a 100644</div><div class="gmail_msg">--- lib/CodeGen/LexicalScopes.cpp</div><div class="gmail_msg">+++ lib/CodeGen/LexicalScopes.cpp</div><div class="gmail_msg">@@ -127,6 +127,9 @@ LexicalScope *LexicalScopes::findLexicalScope(const DILocation *DL) {</div><div class="gmail_msg"> LexicalScope *LexicalScopes::getOrCreateLexicalScope(const DILocalScope *Scope,</div><div class="gmail_msg"> const DILocation *IA) {</div><div class="gmail_msg"> if (IA) {</div><div class="gmail_msg">+ if (Scope->getSubprogram()->getUnit()->getEmissionKind() ==</div><div class="gmail_msg">+ DICompileUnit::NoDebug)</div><div class="gmail_msg">+ return getOrCreateLexicalScope(IA->getScope());</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">I had to change the above line slightly, to:</div><div class="gmail_msg"> return getOrCreateLexicalScope(IA);</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(which essentially ends up mapping to: "return getOrCreateLexicalScope(IA->getScope(), IA->getInlinedAt());")</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Otherwise, with the source file I tried, I the new recursive call to getOrCreateLexicalScope (where the IA->getScope() passed it was also in the NoDebug CU) ended up calling getOrCreateRegularScope, which asserted because Parent==nullptr and CurrentFnLexicalScope != nullptr.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Does my tweak make sense?</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I verified that your change + my tweak (along with the original fix in extractLexicalScopes) allows the entire internal app to build.</div></div></div></div></blockquote><div><br>Cool - I'm trying to understand/think about whether the original fix in extractLexicalScopes is avoidable - I'd like to try to consolidate/collapse the state space as much as possible rather than having several pieces, if possible.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">However, I went back and tried your below test case with these changes + some extra assertion checking. I added asserts in getOrCreateLexicalScope on the new LexicalScope returned by both getOrCreateInlinedScope and getOrCreateRegularScope, to ensure that neither is from a NoDebug CU.<br></div></div></div></div></blockquote><div><br>Ah, good idea!<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Without the above fix, we as expected hit one of these asserts when we have called getOrCreateInlinedScope for f3, when extracting lexical scopes for f4 (which has f3 and f2 inlined into it).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">However, with the above fix, we hit the assert when checking the return of getOrCreateRegularScope. This happens when extracting lexical scopes for f3, which has f2 inlined into it. </div></div></div></div></blockquote><div><br></div><div>f3 is the nodebug function, right? I imagine LexicalScopes should never be built for f3. So I'd probably look at why they're built at all, rather than trying to make building them work (& again, could have an assertion to check that it never happens)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">In that case when we call getOrCreateLexicalScope for the Scope f3 (invoked from getOrCreateInlinedScope for f2), it does not have an inlinedAt so we instead invoke getOrCreateRegularScope, which did not have the new check. Interestingly, this does not hit the original AsmPrinter failure I saw when trying to generate dwarf DIEs. However, I assume we want to be consistent and not have the LexicalScope generated ever for a NoDebug CU's SPs, right?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I fixed the above issue by adding the following before invoking getOrCreateRegularScope from getOrCreateLexicalScope:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="gmail_msg"> if (Scope->getSubprogram()->getUnit()->getEmissionKind() ==</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="gmail_msg"> DICompileUnit::NoDebug)</div><div class="gmail_msg"> return nullptr;</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think it may be useful to add in some NDEBUG assertion checking like the kind I had that caught the above issue, to ensure we never create a LexicalScope for a NoDebug CU - does that sound reasonable? I am going to rebuild the internal app with the above fix and assertion checking added.</div></div></div></div></blockquote><div><br></div><div>Sure, sounds reasonable/good. Not sure which/where the best spot for the asserts would be, but certainly sounds like suring up some invariants here would be a good thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Also, I noticed that one of the first things done in both getOrCreateInlinedScope and getOrCreateRegularScope is:</div><div class="gmail_msg"> Scope = Scope->getNonLexicalBlockFileScope();<br class="gmail_msg"></div><div class="gmail_msg">Do we need to check this resulting Scope, or will it always be the case that both the original and new Scope above will come from the same CU? I am not familiar with LexicalBlockFileScope and there aren't any comments about this class in DebugInfoMetadata.h. =(</div></div></div></div></blockquote><div><br>LexicalBlockFile is for changes to the current file that don't change the scope (eg: if a file is textually #included inside a function definition, the file would change). Scope->getSubprogram() and Scope->getNonLexicalBlockFileScope()->getSubprogram() should always be the same, I believe.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks,</div><div class="gmail_msg">Teresa</div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="m_8095805773368322678gmail-m_5490049026779165918gmail-HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Teresa</div></font></span><div class="gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-h5 gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"> // Create an abstract scope for inlined function.</div><div class="gmail_msg"> getOrCreateAbstractScope(Scope);</div><div class="gmail_msg"> // Create an inlined scope for inlined function.<br class="gmail_msg"><br class="gmail_msg">And here's my test case:<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ cat a.cpp</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">void f1();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">__attribute__((always_inline)) void f2() {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg"> f1();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">}</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">void f3();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">void f4() {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg"> f3();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">}</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ cat b.cpp</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">void f2();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">__attribute__((always_inline)) void f3() {</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg"> f2();</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">}</font></div></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ clang++ -flto a.cpp -g -c</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ clang++ -flto b.cpp -Rpass=inline -c</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ llvm-link {a,b}.o -o - | opt -O2 - -o ab.bc</font></div><div class="gmail_msg"><font face="monospace" class="gmail_msg">$ llc ab.bc</font></div><br class="gmail_msg"><br class="gmail_msg">It might be worth testing with more than one level of nodebug function in the middle (f2_1, f2_2) - my first pass I called "getOrCreateRegularScope" which would've been incorrect in that case, I think. (you could change it back to that, demonstrate that it breaks, and that using getOrCreateLexicalScope fixes it - if you like) - I'm not sure I'd bother committing such test cases - this one seems to suffice, but just for some general confidence in the change.<br class="gmail_msg"><br class="gmail_msg">But it's probably good as-is/without worrying too much, I think.<br class="gmail_msg"><br class="gmail_msg">- Dave<div class="gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-h5 gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Feb 14, 2017 at 9:48 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">On Tue, Feb 14, 2017 at 9:41 AM Teresa Johnson via Phabricator <<a href="mailto:reviews@reviews.llvm.org" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"></div><blockquote class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">tejohnson added inline comments.<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
================<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
Comment at: lib/CodeGen/LexicalScopes.cpp:82<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+ // Ignore locations linked from a NoDebug compile unit.<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+ auto *SP = dyn_cast<DISubprogram>(MIDL->getScope());<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+ if (SP && SP->getUnit()->getEmissionKind() == DICompileUnit::NoDebug) {<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
----------------<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
dblaikie wrote:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> This probably won't catch all cases - if the location was in a subscope within the function (eg: try adding a {} to the function which should add an extra scope). Walking the scope chain until a DISubprogram is probably needed here - I forget if we have a nice wrapped up utility for that. Don't see one at a glance.<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> It should be an invariant/guaranteed that a DISubprogram is reached (& is the end of the scope chain), so something like:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> oh, wait, no, here it is: <a href="http://llvm.org/docs/doxygen/html/classllvm_1_1DILocalScope.html#a747dd1690fc477a8d9638fa37a30ced8" rel="noreferrer" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" target="_blank">http://llvm.org/docs/doxygen/html/classllvm_1_1DILocalScope.html#a747dd1690fc477a8d9638fa37a30ced8</a><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> so, I think, maybe:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> if (cast<DILocalScope>(MIDL->getScope())->getSubprogram()->getUnit()->getEmissionKind() == DICompileUnit::NoDebug) {<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> ...<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
I had just found the DILocalScope::getSubprogram() helper, since I was still getting the original seg fault when I tried the original failing internal code with this change. So now I have:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
// Ignore locations linked from a NoDebug compile unit.<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
auto *SP = MIDL->getScope()->getSubprogram();<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
if (SP->getUnit()->getEmissionKind() == DICompileUnit::NoDebug) {<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
PrevMI = &MInsn;<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
continue;<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
}<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
(Don't need to cast MIDL->getScope() since it returns a DILocalScope).</blockquote><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"></div></div></div><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">Ah, handy!</div></div></div><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"> </div><blockquote class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> But I am *still* getting the original seg fault. Any idea what else I could be missing?<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"></blockquote><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"></div></div></div><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">Not sure, no, sorry :/ I know reducing LTO test cases is difficult, but if this works for the simple test case and doesn't in the original failing situation it'll be good to understand why.</div></div></div><div dir="ltr" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg"> </div><blockquote class="gmail_quote m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
================<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
Comment at: test/DebugInfo/Generic/debug_and_nodebug_CUs.ll:4<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+; RUN: llc %s -o - | FileCheck %s<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
+; CHECK-DAG: # debug.c:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
----------------<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
dblaikie wrote:<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
> Include the steps for reproducing this test case (basically the RUN lines, and the original C source/steps for producing the IR, from the first version of the test) - helps to visualize/document/reproduce the situation.<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
Will do<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<a href="https://reviews.llvm.org/D29765" rel="noreferrer" class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg" target="_blank">https://reviews.llvm.org/D29765</a><br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
<br class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail-m_8251086938961588333gmail_msg gmail_msg">
</blockquote></div></div></blockquote></div></div></div></div>
</blockquote></div></div></div><br class="gmail_msg"><br clear="all" class="gmail_msg"><span class="m_8095805773368322678gmail-m_5490049026779165918gmail- gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>-- <br class="gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail-m_5704362587694747824gmail_signature gmail_msg"><span style="font-family:times;font-size:medium" class="gmail_msg"><table cellspacing="0" cellpadding="0" class="gmail_msg"><tbody class="gmail_msg"><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small" class="gmail_msg"><td nowrap style="border-top:2px solid rgb(213,15,37)" class="gmail_msg">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)" class="gmail_msg"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)" class="gmail_msg"> <a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)" class="gmail_msg"> <a href="tel:(408)%20460-2413" value="+14084602413" class="gmail_msg" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</span></div></div>
</blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>-- <br class="gmail_msg"><div class="m_8095805773368322678gmail-m_5490049026779165918gmail_signature gmail_msg"><span style="font-family:times;font-size:medium" class="gmail_msg"><table cellspacing="0" cellpadding="0" class="gmail_msg"><tbody class="gmail_msg"><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small" class="gmail_msg"><td nowrap style="border-top:2px solid rgb(213,15,37)" class="gmail_msg">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)" class="gmail_msg"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)" class="gmail_msg"> <a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)" class="gmail_msg"> <a href="tel:(408)%20460-2413" value="+14084602413" class="gmail_msg" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</div></div></blockquote></div></div>