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

Aaron Ballman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 3 09:17:54 PST 2020


aaron.ballman added a comment.

In D90275#2371343 <https://reviews.llvm.org/D90275#2371343>, @jdoerfert wrote:

> The more I think about it, the more I think we should never create a `leaf`/`nocallback` definition. Only declarations should carry that attribute.

When talking about the IR that gets lowered to LLVM, I think that's very reasonable. When talking about the frontend, I'm a bit less certain. GCC and ICC both do not warn when you apply the attribute solely to a definition, so one concern is with code portability where existing code is harder to port into Clang. However, when I tried to find examples of the attribute being written on a definition, I couldn't spot any so this may not be a particularly large concern.

Another potential concern is that a situation like this seems harmless and diagnosing the use on the definition seems user-unfriendly:

  // In a header file
  __attribute__((leaf)) void func(void);
  
  // In a source file
  __attribute__((leaf)) void func(void) { ... }

The last concern is whether non-compiler-writing users will understand the behavior.

  // #1
  __attribute__((leaf)) void func(void) {} // Declares and defines a function at the same time
  
  // #2
  __attribute__((leaf)) void func(void);
  void func(void) {} // Inherits the attribute from the previous declaration

I would suspect that users will see #1 and #2 as defining the same things and may be surprised if #1 is diagnosed but #2 is fine, but that's just a gut feeling without evidence backing it up.

I'm not insisting that we accept the attribute on a definition, but if we do want to make a distinction in the frontend between declaration and definition, we should document it with some explicit examples.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275



More information about the llvm-commits mailing list