[PATCH] D119061: [Clang] noinline call site attribute

Dávid Bolvanský via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 10 14:31:29 PST 2022


xbolva00 added a comment.

>> It would be good to check with a language expert if this can break some code. I'm thinking of situations when someone relies on a function being emitted (or not) and ending up with linking issues. I'm not an expert here, but this is a past concern I vaguely remember.

currently flatten attribute is implemented in way that always_inline attribute is attached to all calls, so inliners already know about call site attributes.

>> if this can break some code

This is totally opt-in, I am not sure how this can break any current codebases, as noinline attribute on statements was strongly rejected.

>> I'm thinking of situations when someone relies on a function being emitted (or not) and ending up with linking issues.

Hm, I am thinking about our common edge case:

always_inline foo() { }

bar () {

  noinline foo();

}

Yes, currently inliner inlines foo() even with noinline as CS attribute. Thanks for idea, if we are gonna switch inliner behaviour to avoid inlining, we need to be careful as inliner may delete foo.

Or maybe just strongly reject conflicting attributes and declare win here? Now I think it could be better idea to emit a warning or an error in this case.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061



More information about the cfe-commits mailing list