<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 26, 2014 at 4:59 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@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 class="HOEnZb"><div class="h5">On Fri, Oct 24, 2014 at 3:27 PM, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>> wrote:<br>
><br>
><br>
> On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> I'm not sure if this was intended, but it's going to be a problem for<br>
>>>>> sample profiles.<br>
>>>>><br>
>>>>> When we compile with -gmlt, the profiler expects to find the line<br>
>>>>> number for all the function headers so that it can compute relative line<br>
>>>>> locations for the profile.<br>
>>>>><br>
>>>>> The tool that reads the ELF binary is not finding them, so it writes<br>
>>>>> out absolute line numbers, which are impossible to match during the<br>
>>>>> profile-use phase.<br>
>>>>><br>
>>>>> The problem seems to be that we are missing DW_TAG_subprogram for all<br>
>>>>> the functions in the file.<br>
>>>>><br>
>>>>> Attached are the dwarf dumps of the same program. One compiled with my<br>
>>>>> system's clang 3.4 and the other with today's trunk. In both compiles, I<br>
>>>>> used -gline-tables-only.<br>
>>>>><br>
>>>>> The trunk version is missing all the subprogram tags for the functions<br>
>>>>> in the file. This breaks the sample profiler.<br>
>>>>><br>
>>>>> Should I file a bug, or is -gmlt going to be like this from now on? The<br>
>>>>> latter would be a problem for us.<br>
>>>><br>
>>>><br>
>>>> Open to negotiation, but this change is intentional ( for details, see<br>
>>>> the commit: <a href="http://llvm.org/viewvc/llvm-project?rev=218129&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=218129&view=rev</a> ).<br>
>>><br>
>>><br>
>>> Well, this breaks us. Very hard. It absolutely blocks us from using<br>
>>> SamplePGO with LLVM.<br>
>><br>
>><br>
>> Sorry about that - I knew ASan needed gmlt data of a certain form and<br>
>> worked carefully to ensure llvm-symbolizer could still symbolize with these<br>
>> changes, but wasn't aware of this particular dependence from PGO (just<br>
>> assumed it used the line table directly).<br>
><br>
><br>
> It does, but it uses relative line numbers. That's why it needs the source<br>
> locs for the function headers.<br>
><br>
>><br>
>><br>
>>><br>
>>> The alternative would be to make the compiler use absolute line numbers,<br>
>>> but in the experience we've collected with GCC, this makes the profiles very<br>
>>> brittle wrt source changes.<br>
>><br>
>><br>
>> It'd be interesting to see the data - I guess you throw out profiles that<br>
>> don't match on a per-function basis? So adding a few lines to one function<br>
>> will invalidate the profile for that function, but not all the subsequent<br>
>> ones in the file?<br>
><br>
><br>
> Right. Dehao started using absolute numbers, but then moved to relative<br>
> numbers when he saw that the performance drops were fairly pronounced as the<br>
> profile aged. I don't recall the exact drops he noticed.<br>
><br>
>><br>
>><br>
>>><br>
>>> I don't have a better idea atm. Would there be any other way to generate<br>
>>> relative line numbers?<br>
>><br>
>><br>
>> Possibly.<br>
>><br>
>>><br>
>>>   Perhaps we could use the first line number we find with samples?<br>
>><br>
>><br>
>> Probably - I guess you use the ELF symbol table to compute the address<br>
>> range of each function? Given that, you could find the smallest line number<br>
>> in that address range in the line table, and make everything else relative<br>
>> to that.<br>
><br>
><br>
> That could probably work, but I'm not sure how the ELF reading code in the<br>
> conversion tool does this calculation. I'll check it out.<br>
><br>
>><br>
>><br>
>>><br>
>>> The problem here is that this line will shift, depending on how the<br>
>>> profile was obtained.<br>
>><br>
>><br>
>> Not sure what you're referring to here ^<br>
><br>
><br>
> Say the function starts at line 20. If in one profile run, we get samples at<br>
> line 20 and line 23, then we'll compute the relative locations as 0 and 3.<br>
> But if the first sample you get is at line 21, then you'll compute the<br>
> relative locations as  0 and 2.<br>
><br>
> Using the address ranges in the line table may be the way to go. I'll look<br>
> at this next week.<br>
><br>
<br>
</div></div>I'm nearly certain this is the way to go here.<br></blockquote><div><br></div><div>How does it solve the problem?</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>