https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #19 from Marco Elver <elver at google dot com> --- (In reply to Fangrui Song from comment #18) [...] > 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? I have mentioned this several times now, but it seems nobody is listening: It's _not_ about inlining -- the inlining discussion is about a particular implementation strategy. It's about the _contract an attribute promises_, which is treating the code in the function a certain way (e.g. do not instrument). That can be done by either: a) even if the code is inlined, respect the original attribute for the inlined code (e.g. do not instrument), or b) just don't inline. It looks like (b) is easier to do. I probably do not understand how hard (a) is. If you break the contract because it's too hard to do (a), then that's your problem. Just don't break the contract. Because that's how we get impossible-to-diagnose bugs. Correctness comes first: if it is impossible for a user to reason about the behaviour of their code due to unspecified behaviour (viz. breaking the contract) of an attribute, then the code is doomed to be incorrect. Therefore, do _not_ implement attributes with either unspecified or ridiculously specified behaviour. Ridiculous in this case is saying "this attribute only does what it promises if you also add noinline". It's ridiculous, because the user will then rightfully wonder "?!?!? Why doesn't it imply noinline then?!?!?!". Thanks.
