[LLVMdev] Recent changes in -gmlt break sample profiling
Xinliang David Li
xinliangli at gmail.com
Sun Oct 26 21:50:16 PDT 2014
On Sun, Oct 26, 2014 at 9:30 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Sun, Oct 26, 2014 at 7:23 PM, Xinliang David Li <xinliangli at gmail.com>
> wrote:
>
>> The fundamental questions we need to answer are the following:
>>
>
> FWIW, there was a longer discussion on the lists when the actual option
> was added. I'll try to relay my memory of that discussion, but you might
> need to track it down or involve some of the other people who participated
> in it. Honestly, this thread is probably not the best place to rehash the
> entire design of this feature...
>
>
>> 1) what is -gmlt option designed for? debugging, profiling, autofdo. Do
>> we expect more use cases for -gmlt?
>>
>
> It was designed for all users of debug information that merely need
> location information rather than variable, type, or other debug
> information. We expect these to at least include any and everything that is
> primarily symbolizing backtraces and analyzing those. I think sample-based
> profiling and PGO is definitely in-scope.
>
> 2) can gmlt's behavior be standardized? The meaning of 'minimal' really
>> varies depending on the target use of the information. What is minimally
>> enough today may become not enough tomorrow if there is a new target use
>> case identified.
>>
>
> Again, the Clang flag is not '-gmlt'. It is '-gline-tables-only'. But I
> think both are clear in their intent... Perhaps we could add some
> documentation for the flag, but I don't think we can or need to try to
> standardize this... It's a pragmatic thing and should continue to be driven
> by pragmatic decisions.
>
>
>> 3) Do we have regression tests for other well established use cases, such
>> as asan?
>>
>
> Both the ASan and TSan test suites should cover this, yes.
>
>
>> 4) When we need to add more debug info for -gmlt in the future for
>> enhancement of one of the existing use cases, is it considered a memory and
>> object size regression and get rejected?
>>
>
> This is really open ended and impossible to answer. It would depend
> entirely on the nature of the enhancement and the impact it had on the
> debug info size. It would likely be discussed and a decision made on the
> lists.
>
So autofdo can not be fully tied with gmlt/gline-table-only because there
is chance in the future that its needed info may not be available?
By the way, in real use cases I have seen, full debug (-g + fission) is
common with optimized binaries, so gmlt constraints may not be a too big
issue.
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141026/395c03f1/attachment.html>
More information about the llvm-dev
mailing list