<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 15, 2016 at 9:58 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 Thu, Dec 15, 2016 at 9:15 AM, 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"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">I suppose this (applying this 'demote to declaration' optimization universally) can be seen as consistent with -fstandalone-debug without needing to be predicated by a flag. -fstandalone-debug tells you something about how the rest of the program you can't see. When you can see it (ThinLTO) you /know/ the type is available, you're not just assuming.<br class="gmail_msg"><br class="gmail_msg">This will be harder to justify/figure out when we eventually move to the next step of treating types the same way we do inline functions (in the summary, specify one module that retains the type definition - all other modules can demote their definitions of that type to a declaration). That's consistent with the philosophy of -fstandalone-debug (because now you /know/ the type is elsewhere) but will break LLDB.</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'm not sure how it is different in practice though than what this patch does for the importing case - in the case where there is information in the index that allows you to demote the other copies to decls, you also /know/ the type is available and aren't assuming - the index tells you that it is in another bitcode module that is being linked in. </div></div></div></div></blockquote><div><br>Just chatted offline, but to summarize (& I think you summarized it better than I was):<br><br>The specific LLDB problem only arises when you could import a definition of a type that depends on a non-imported (declaration-only) of another type (specifically in an inheritance relationship, but could come up in others I'm sure). If we only import everything from another module as declarations this doesn't arise. But if we started not importing some things, but importing others (from the current module itself) we could create these kinds of situations LLDB can't handle.<br><br>(but, all that aside - a story/problem for another time, as Aprantl pointed out - this doesn't come up here, but will in the future)<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><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-5603849412190971252HOEnZb gmail_msg"><div class="m_-5603849412190971252h5 gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, Dec 15, 2016 at 9:05 AM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" class="gmail_msg" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added a comment.<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
Mehdi and I just ran a couple of experiments. LLDB can find forward-declared composite types that are defined in another .o file just fine; the only caveat is that LLDB has to potentially load the accelerator table of each .o file from disk in order to find the .o file with the definition in it. Judging from this, I think that this approach is fine.<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<a href="https://reviews.llvm.org/D27775" rel="noreferrer" class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg" target="_blank">https://reviews.llvm.org/D27775</a><br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
<br class="m_-5603849412190971252m_2572576342128974521gmail_msg gmail_msg">
</blockquote></div>
</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_-5603849412190971252gmail_signature gmail_msg" data-smartmail="gmail_signature"><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-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px" class="gmail_msg">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px" class="gmail_msg"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px" class="gmail_msg"> <a href="mailto:tejohnson@google.com" class="gmail_msg" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px" 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>