[PATCH] D104475: [Clang][Codegen] emit noprofile IR Fn Attr for new Fn Attr no_profile

Thu Jun 17 14:19:45 PDT 2021

melver added a comment.

In D104475#2825297 <https://reviews.llvm.org/D104475#2825297>, @MaskRay wrote:

> Should `no_profile` specify the inlining behavior? Though `no_sanitize_*` don't specify that, either.

I think it's somehow implicit, but I can't quite say how. There are some tests that check this, e.g.
compiler-rt/test/asan/TestCases/inline.cpp

> As I commented on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 , the Linux kernel specifies `noinline` so the exact inlining behavior doesn't matter.
>
>   #define noinstr                                                         \
>           noinline notrace __attribute((__section__(".noinstr.text")))    \
>           __no_kcsan __no_sanitize_address

noinstr does add noinline, but other uses of the attribute alone might not. But in the end inlining is a red herring, it just seems to be the easiest way to enforce the promised contract.  See https://lore.kernel.org/lkml/CANpmjNNRz5OVKb6PE7K6GjfoGbht_ZhyPkNG9aD+KjNDzK7hGg@mail.gmail.com/

In particular:

> But the contract of
> "no_sanitize" is "that a particular instrumentation or set of
> instrumentations should not be applied". That contract is broken if a
> function is instrumented, however that may happen.

Also always_inline needs checking, because it's a little special:

>>>> - An __always_inline function inlined into a __no_sanitize function is not instrumented
>>>> - An __always_inline function inlined into an instrumented function is instrumented

This was also previously discussed here: https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com/

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104475