<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 5:56 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><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"><span class=""><br>
> On 2015-Sep-01, at 16:07, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Sep 1, 2015 at 3:59 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> Way back in r107027, we started preserving type information of local<br>
> variables of functions that are optimized away.  This seemed strange to<br>
> me so I dug into the history: apparently, this is so that ctfconvert can<br>
> find these types (so they can be exposed in dtrace).<br>
><br>
> E.g., this commit made it so that for this C code:<br>
><br>
>     static void foo(void) { struct X { int b; } v; }<br>
><br>
> we always get the type information for foo.v, even if foo() is optimized<br>
> away.<br>
><br>
> I came across this when trying to reverse the direction of the IR's<br>
> DICompileUnit/DISubprogram links.  r107027 effectively forces us to<br>
> hold onto subprogram definitions that describe deleted functions.<br>
><br>
> Aside: there's a CR currently underway on llvm-dev about whether we should (or should not) emit declarations for functions that have been optimized away (neglecting local variables/types/etc, we currently emit a function declaration for a function even if it gets inlined and optimized away - it's unclear if that's the right call (given that we don't emit declarations for functions that are never called, I'm not sure there's a strong argument to be made to keep these, but I'm undecided)). So if you're interested in removing optimized-away subprogrcams, you might want to weigh in on that thread.<br>
<br>
</span>I can't find the thread :(.  Can you give me the subject line?<br></blockquote><div><br><span style="font-size:17.6000003814697px">D12426 (should find you the thread, etc)</span><br> </div><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">
<br>
I'm guessing it's something along the lines of deleting this block:<br>
--<br>
    if (!D && !includeMinimalInlineScopes())<br>
      // Lazily construct the subprogram if we didn't see either concrete or<br>
      // inlined versions during codegen. (except in -gmlt ^ where we want<br>
      // to omit these entirely)<br>
      D = getOrCreateSubprogramDIE(SP);<br>
--<br>
in DwarfCompileUnit::finishSubprogramDefinition()? </blockquote><div><br>Yep, more or less.<br> </div><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"> That was something<br>
I was planning on bringing up next...<br>
<span class=""><br>
> For my money I'd apply a similar logic to those types: we don't emit any number of types we know during IRGen are unused, so I'm not sure there's a good reason to keep them if we discover they're unused a bit later.<br>
<br>
</span>Yeah, it seems like the logic should be pretty similar.<br>
<div class=""><div class="h5"><br>
><br>
> This<br>
> seems quite weird to me :/.<br>
><br>
> I'm talking to people internally and hoping to find that we just don't<br>
> care anymore.  Even if we do, perhaps shoving these types into<br>
> 'retainedTypes:' in `DICompileUnit` (only if -gkeep-all-types or some<br>
> such) will solve the problem for the ctfconvert use case (without<br>
> burdening others).<br>
><br>
> While I sort that out... does anyone else rely on this?  How?  Why?<br>
><br>
> (The attach patch effectively reverts r107027.)<br>
<br>
</div></div></blockquote></div><br></div></div>