On Wed, Jun 23, 2021 at 6:15 AM Martin Liška <mli...@suse.cz> wrote: > > On 6/23/21 2:38 PM, Jan Hubicka wrote: > > Is there reason to prevent the inlining once instrumentation is done? > > No ;)
Here's another case that coincidentally came up yesterday. How should these attributes behave in the case of __attribute__((flatten)) on the caller? Another case which is curious is what happens when the callee has __attribute__((always_inline)) and there's a conflict? In LLVM, the current behavior is: "__attribute__((no_stack_protector)) and __attribute__((no_profile_instrument_function)) will prevent inline substitution when the attributes do not match between caller and callee, unless the callee was attributed with __attribute__((always_inline)) or the caller was attributed with __attribute__((flatten))." We have some overzealous users of always_inline and flatten in Android. They are currently playing whack-a-mole with no_stack_protector. I'm not sure yet how we can better help them self diagnose, or whether we should consider a change in policy. I'm also not sure whether GCC's einliner corresponds with always_inline or not necessarily? -- Thanks, ~Nick Desaulniers
