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?
