[llvm-dev] (RFC) Encoding code duplication factor in discriminator

[David Blaikie via llvm-dev]

yep, +1, seems like a -f flag to me. (you'd want to be able to combine it
with any other level of debugging - no need to have to choose between
profiling or debugging)

On Tue, Nov 22, 2016 at 3:46 PM Greg Bedwell <gregbedwell at gmail.com> wrote:

> For our users we fully expect their profile/debug builds to be the same
> thing (that is, almost all debugging is on fully optimized code, where
> fully optimized also means part of an iterative profiling workflow).
> Having extra debug information that only benefits the profiling part seems
> reasonable.  What would be unacceptable is if we ever had to ask our users
> to make a trade off between debug info that was best for profiling at the
> expense of debugging quality or vice versa.  The "-femit-debug-for-profiling"
> flag seems to fit this model of it being more a strict superset rather than
> a tuning option more clearly.
>
>
> -Greg
>
> On 22 November 2016 at 23:16, Dehao Chen via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> -gprofile should have:
>
> 1. emit linkage name in all subprograms
> 2. emit discriminator with dup-factor copy-factor encoded
> 3. use-unknown-locations=true
>
> Here comes the problem: is it an intermediate -g mode between -g1 and -g2?
> If yes, this means that -g2 will also need to include all the 3 items
> above. If not, then it should not be called -gprofile, but rather a flag
> like -femit-debug-for-profiling", so that we can use it with "-g2
> -femit-debug-for-profiling", or "-gmlt -femit-debug-for-profiling".
>
>
Yep, sounds about right (should have a -fno- option too, should it imply -g
of some kind if you specify it alone? I'd prefer to avoid implication
(implies flags get weird/hard to handle imho) if possible. Just have a
reasonable recommendation of -gmlt -fprof-debug or whatever we call it (I'm
bad with names))

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161123/a5d9c324/attachment.html>