[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223

--- Comment #18 from Fangrui Song <i at maskray dot me> ---
(In reply to Nick Desaulniers from comment #15)
> (In reply to Fangrui Song from comment #14)
> > Can a no_profile_instrument_function function be inlined into a function
> > without the attribute? This may be controversial but I'd argue that it can.
> > GCC no_stack_protector behaves this way. no_profile_instrument_function can
> > mean that user does not want profiling when the function is called with its
> > entity, not via another entity.
> 
> I respectfully but strongly disagree. It's surprising to developers when
> they ask for no stack protector, or no profiling instrumentation, then get
> one anyways.  For long call chains, it's hard for developers to diagnose on
> their own which function they called that missed such function attribute.
> 
> This reminds me of "what color is your function?"
> https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
> As suddenly a developer would need to verify for a no_* attributed function
> that they only call no_* attributed functions, or add noinline (which is a
> big hammer to all call sites, and games with aliases that have the noinline
> attribute are kind of ridiculous).
> 
> It's less surprising to prevent inline substitution upon function attribute
> mismatch. Then a developer can self diagnose with -Rpass=inline. Either way,
> some form of diagnostics would be helpful for these kinds of issues, and has
> been requested by Android platform developers working on Zygote.
> 
> For no_stack_protector in LLVM, I implemented the rules: upon mismatch,
> prevent inline substitution unless the user specified always_inline.  This
> fixed suspend/resume bugs in x86 Linux kernels when built with LTO.
> 
> Though, I'm happy to revisit that behavior in LLVM; we could add
> 
> #define noinline_for_lto __attribute__((__noinline__))
> 
> then use that in the Linux kernel instead.

Our problem is that a boolean attribute with 1 bit information cannot express
whether a neg attribute function can be inlined into a pos attribute function.

Let's agree to disagree. I don't see why a no_profile_instrument_function
function suppress inlining into a function without the attribute. For the use
cases where users want to suppress inlining, they can add noinline. What I
worry about is that now GCC has an attitude and if the LLVM side doesn't follow
it is like diverging. However, the GCC patch is still in review. I think a
similar topic may need to be raided on llvm-dev side as I feel this is the tip
of the iceberg - more attributes can be similarly leveraged. So, how about a
llvm-dev discussion?