<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 28, 2014 at 3:21 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"><div class="">I agree that this isn't useful for PGO, but the profile data is also useful<br></div>
for code coverage.<br>
<br>
Given profile data, consider answering the questions:  "What functions were<br>
instrumented?  Which of these had no coverage?"  I'm not sure how to answer<br>
those questions accurately without these counters.<br>
<br>
This still leaves coverage gaps in never-used templated code, but that's a<br>
different can of worms.</blockquote><div><br></div><div>Emitting all inline functions seems like it will require semantic changes and it's overkill.  The specific case I'm thinking of is:</div><div>#include <memory></div>
<div>struct Bar;</div><div>struct Foo {</div><div>  Foo(Bar *b) : p(b) {}</div><div>  std::unique_ptr<Bar> p;<br>};</div><div><br></div><div>We need to require a complete type for Bar if we want to emit ~Foo, because ~unique_ptr<Bar> deletes Bar, but we don't require that currently.</div>
<div><br></div><div>I don't know the details of coverage, but is there another way to represent "I saw this inline function, but nobody called it"?  My straw man suggestion is to emit a single counter for the entry block that will either always be zero or be comdat merged with another TU that uses the inline function.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> Also, CodeGenerator::HandleInlineMethodDefinition() would be a better place for this code.  We recently added it for dllexport, which has basically the semantics you want.  If this ends up being the direction we want, we probably want to merge support for -femit-all-decls, pgo, and dllexport in the same place to control the linkage and MustBeEmitted-ness of inline functions.<br>

<br>
</div>That sounds like a better design (assuming you agree on the direction).<br>
</blockquote></div><br></div></div>