https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
Nick Desaulniers <ndesaulniers at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |elver at google dot com,
| |isanbard at gmail dot com,
| |kees at outflux dot net,
| |maskray at google dot com,
| |ndesaulniers at google dot com
--- Comment #6 from Nick Desaulniers <ndesaulniers at google dot com> ---
We had a request for something like this today on LKML, see the thread.
https://lore.kernel.org/lkml/cakwvodmpti93n2l0_yqkrzldmpxzror7zggszonyaw2pgsh...@mail.gmail.com/
And more specific use case:
https://lore.kernel.org/lkml/20210614190700.gf68...@worktop.programming.kicks-ass.net/
I've implemented this in LLVM; no_instrument_function function attribute in C
can be used to disable coverage of -fprofile-generate (instrumentation based
profiling; "PGO") and -fprofile-arcs (coverage; "GCOV").
PGO: https://reviews.llvm.org/D104253
GCOV: https://reviews.llvm.org/D104257
Inlining is a good point and something I'll need to check; generally when
caller's and callee's function attributes don't match, we block inline
substitution (though we permit it for always_inline; developer be damned).
One question Fangrui had made was whether no_instrument_function is the
appropriate function attribute to re-use.
https://reviews.llvm.org/D104253#2817695
It looks like both -finstrument-functions and -pg are affected by attribute
no_instrument_function; I decided to reuse no_instrument_function in LLVM
because:
1. it already exists; implementation is barely more than 1 LoC.
2. it already affects code gen of 2 different flags.
3. its name perfectly describes developer intent.
4. the Linux kernel is already wired up to make use of no_instrument_function
attribute (though the kernel's configuration step (KConfig) will need changes
to detect support for this issue probably).
I haven't landed the changes in LLVM yet, and don't particularly care what the
attribute used ultimately is even if that means revisting our approach in LLVM.
But without a solution to this problem, it's likely to block PGO and regress
GCOV for x86 Linux kernels.
