<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 3:59 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. </blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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>
</blockquote></div><br></div></div>