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