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

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

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 the caller of leaf() is at a.c, not b.c.
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.

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).
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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275