Figured it had been. Might still be interesting, but I can see where the function level relative offset is a decent compromise.<div><br></div><div>-eric<br><br><div class="gmail_quote">On Sun Oct 26 2014 at 7:31:19 PM Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Alternatives like this were discussed during autofdo's original design. For instance fetching the source diff and establish line mapping between two revisions. Another one is to use more fine grained offsets in profile to have better source change tolerance.  We ended up with function level relative offset solution which is the simplest and works fine in practice. (It is not designed to handle large scale refactoring).</div><div dir="ltr"><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 26, 2014 at 4:25 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"><span>On Sun, Oct 26, 2014 at 3:47 PM, Jeremy Lakeman<br>
<<a href="mailto:Jeremy.Lakeman@gmail.com" target="_blank">Jeremy.Lakeman@gmail.com</a>> wrote:<br>
> This sounds like a problem best solved by tracking source code movement via<br>
> your source control system.<br>
> If you know the commit of the code that produced the sample, you should be<br>
> able to use source control history / diffs to translate absolute line<br>
> numbers to the location where the source has moved.<br>
> This would have the added advantage of highlighting where those samples are<br>
> likely to be useless or completely misleading.<br>
<br>
</span>This particular scheme might not work, but I was thinking of something<br>
similar last week.<br>
<br>
Basically you'd use the same algorithms that the source control system<br>
uses when merging or doing whitespace only diffs etc to construct a<br>
better correspondence between source lines. The problem then comes<br>
down to "we added some hot code that doesn't have any samples" at<br>
which point you'd want the optimizer to pay attention to propagating<br>
weights along edges without them.<br>
<br>
Anyhow, some food for thought.<br>
<span><font color="#888888"><br>
-eric<br>
</font></span><div><div><br>
><br>
> On Sat, Oct 25, 2014 at 8:57 AM, Diego Novillo <<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>>><br>
>>> On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <<a href="mailto:dnovillo@google.com" target="_blank">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" target="_blank">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" target="_blank">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?<br>
>>>>>> The 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<br>
>> at line 20 and line 23, then we'll compute the relative locations as 0 and<br>
>> 3. 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>
>> Diego.<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
>><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
</blockquote></div></div>