[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