llvm dev - Oct 2014 - [LLVMdev] Recent changes in -gmlt break sample profiling

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141026/e5d49197/attachment.html>

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>

On Sun, Oct 26, 2014 at 9:50 PM, Xinliang David Li <xinliangli at
gmail.com>
wrote:
> 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?

That's not what I'm saying at all?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141026/994cc732/attachment.html>