[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D90275#2371764 <https://reviews.llvm.org/D90275#2371764>, @aqjune wrote:

> Hi,
>
> Naming is a hard thing... I have no special preference. :/
>
> However, I'd like to understand the details of this attribute.
>
> Would LTO be affected because `leaf` is guaranteed to untouch the current translation unit only?
>
>   // a.c
>   int x;
>   void f1() {
>     f2();
>   }
>   void g() { x = 3; }
>   
>   // b.c
>   void f2() {
>     leaf();
>   }
>   
>   // leaf.c
>   attribute((leaf)) void leaf() {
>     g();
>   }
>
> IIUC this program is okay because g() and the caller of leaf() are in different TUs.
> But, let's assume that a.c and b.c are LTO-ed, and leaf.c is separately compiled.
> If LTO merges a.c and b.c into the same module, the two TUs cannot be distinguished anymore; either `leaf` should be dropped, or LTO should somehow conceptually keep two TUs.
> Would it be a valid concern? Then I think it should be mentioned.

As noted by the GCC docs, it doesn't mean anything on a definition so that you can safely merge TUs. I want us to forbid `leaf` on IR function definitions for that reason, it would not mean anything and be only confusing.

> Another question is more about the motivation of this attribute (well, I know it is introduced by gcc first; just throwing a question :) )
> If the motivation is to support better data flow analysis, is there something special in callback itself?
> The gcc document states that `sin()` is a leaf function, and IIUC this is because `sin()` never touches the memory allocated at caller's TU (because `errno` isn't at the caller's TU).

No, that is not it. It is `leaf` because it will not transfer control to the callers TU.

> I think things are easier if we simply say that `leaf` cannot touch the memory of current TU, regardless of the existence of callbacks.
> Is there something important in the callback itself?

Not really, IMHO, `leaf` means you cannot transfer control to the callers TU without going threw the original call site (via return or throw).
It is not a memory thing. However, the "almost" matching memory property is called `inaccesiblememonly` so that is why I wanted to call this `inaccessiblecodeonly`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275