<div dir="ltr">My slides from EuroLLVM regarding coverage, in case you are interested...<div><a href="http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/EuroLLVM'14%20--%20ASan%20%2B%20Coverage.pdf">http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/EuroLLVM'14%20--%20ASan%20%2B%20Coverage.pdf</a><br>
</div><div><br></div><div>--kcc </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 2:13 AM, 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=""><br>
On Mar 31, 2014, at 10:45, Bob Wilson <<a href="mailto:bob.wilson@apple.com">bob.wilson@apple.com</a>> wrote:<br>
<br>
><br>
> On Mar 31, 2014, at 1:53 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>><br>
>> This is what I see on 483.xalancbmk:<br>
>>  15 __llvm_prf_names 0036fcb0  00000000010abf40  00000000010abf40  00cabf40  2**5<br>
>>  16 __llvm_prf_data 001b77e0  000000000141bc00  000000000141bc00  0101bc00  2**5<br>
>>  32 __llvm_prf_cnts 00123468  0000000001af2fe0  0000000001af2fe0  014f2fe0  2**5<br>
>><br>
>> __llvm_prf_names is larger than the other two combined.<br>
>> 483.xalancbmk is C++ and the function names are long. The same is true for most of the code we care about.<br>
>> Can't we use function PCs instead of function names in this table (and retrieve the function names from debug info)?<br>
><br>
> That’s a bit surprising. We should check to make sure there isn’t anything obviously wrong.<br>
<br>
</div>I'm surprised too, but it makes some sense.<br>
<br>
  - Most functions in the implementation details of the STL have long enough mangled<br>
    names (and little enough control flow) that the names would dominate the size<br>
    overhead.<br>
<br>
  - Many class member functions will have this property, too, like getters, setters,<br>
    and typical constructors, copy/move operators, and destructors.<br>
<br>
There's likely a way to emit these names more compactly using a tree (with links<br>
to parent nodes).<br>
<br>
Consider _ZN9Namespace5Class3fooEv, the mangled name for Namespace::Class::foo().<br>
We could do something like this:<br>
<br>
    %__llvm_profile_name = type {i8*, %__llvm_profile_name*}<br>
<br>
    @__llvm_profile_str__ZN = linkonce constant [4 x i8] c"_ZN\00"<br>
    @__llvm_profile_name__ZN = linkonce constant %__llvm_profile_name {<br>
      i8* getelementptr ([4 x i8]* @__llvm_profile_str__ZN, i32 0, i32 0),<br>
      %__llvm_profile_name* null }<br>
<br>
    @__llvm_profile_str_9Namespace = linkonce constant [11 x i8] c"9Namespace\00"<br>
    @__llvm_profile_name__ZN9Namespace = linkonce constant %__llvm_profile_name {<br>
      i8* getelementptr ([11 x i8]* @__llvm_profile_str_9Namespace, i32 0, i32 0),<br>
      %__llvm_profile_name* @__llvm_profile_name__ZN }<br>
<br>
    @__llvm_profile_str_5Class = linkonce constant [7 x i8] c"5Class\00"<br>
    @__llvm_profile_name__ZN9Namespace5Class = linkonce constant<br>
      %__llvm_profile_name {<br>
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_5Class, i32 0, i32 0),<br>
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace }<br>
<br>
    @__llvm_profile_str_3fooEv = linkonce constant [7 x i8] c"3fooEv\00"<br>
    @__llvm_profile_name__ZN9Namespace5Class3fooEv = linkonce constant<br>
      %__llvm_profile_name {<br>
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_3fooEv, i32 0, i32 0),<br>
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace5Class }<br>
<br>
Then _ZN9Namespace5Class3barEv (Namespace::Class::bar()) would be cheap.<br>
<br>
    @__llvm_profile_str_3barEv = linkonce constant [7 x i8] c"3barEv\00"<br>
    @__llvm_profile_name__ZN9Namespace5Class3barEv = linkonce constant<br>
      %__llvm_profile_name {<br>
      i8* getelementptr ([7 x i8]* @__llvm_profile_str_3barEv, i32 0, i32 0),<br>
      %__llvm_profile_name* @__llvm_profile_name__ZN9Namespace5Class }<br>
<br>
These would merge cleanly even between object files generated from different<br>
translation units.<br>
<br>
Doing it like that requires understanding the mangling and wouldn't compact common<br>
prefixes in C.  We could do something similar with a heuristic (split every 8<br>
characters), or split on common prefixes per translation unit (and hope they line up<br>
between translation units).<br>
<br>
</blockquote></div><br></div>