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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
