<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 9:15 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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><br>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><br></div><div>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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 15, 2016 at 9:05 AM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added a comment.<br class="m_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_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_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_msg">
<a href="https://reviews.llvm.org/D27775" rel="noreferrer" class="m_2572576342128974521gmail_msg" target="_blank">https://reviews.llvm.org/<wbr>D27775</a><br class="m_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_msg">
<br class="m_2572576342128974521gmail_msg">
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" 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"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>