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

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:3910
+Functions marked as ``leaf`` attribute are not allowed to enter their caller's translation unit.
+Therefore, they cannot use or modify any data that does not escape the current compilation unit.
+
----------------
gulfem wrote:
> aaron.ballman wrote:
> > What sort of diagnostic checking should the user expect? e.g., can the user expect Clang to diagnose obviously incorrect code like:
> > ```
> > [[gnu::leaf]] void func(void (*fp)(void)) {
> >   fp(); // This seems like a bad thing
> > }
> > ```
> This is a compiler hint provided by the user, and if the user misuses that attribute, it might result in undefined behavior.
> I think it might be difficult to fully verify that leaf function does not enter into caller's translation unit.
> For this simple case you provided, it might be easy to add such a check.
> However, it might be difficult to add such checks for complicated cases.
> Therefore, we were not planning to add such kind of diagnostic checking.
> What do you think?
@aaron.ballman, your code example is not " obviously incorrect " and we should not diagnose that (see below). In fact, I doubt we can ever diagnose misuse except during the LTO linking stage, assuming the expected use case. That said, you could warn and ignore if a function definition is annotated.

```
// library.c
void bar(void) {}

[[gnu::leaf]] void func(void (*fp)(void)) {
  fp(); // not necessarily a bad thing
}
// user.c
#include <library.h>
void test() {
  func(&bar); // perfectly fine.
}

```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275