https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
Bug ID: 101279
Summary: Function attributes often block inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
When using many function attributes, the attributes only apply when the
function is not inlined. And in some cases, they actively disable inlining
which would normally be expected.
For example, a programmer may have occasional need for two's complement
wrapping semantics for signed integers. They don't want to use "-fwrapv"
globally, because that would lose some optimisation opportunities for the rest
of the code. So they define functions like "wrapped_add" :
__attribute__((optimize("-fwrapv")))
static inline int wrapped_add(int a, int b) {
return a + b;
}
int foo(int x, int y, int z) {
return wrapped_add(wrapped_add(x, y), z);
}
When used in a function like "foo" which does not have "-fwrapv" active,
function calls are made rather than the expected inlining. The result is
significantly poorer code than the programmer would predict.
If "foo" also has "-fwrapv" from a compiler flag, attribute or pragma, the
generated code is inlined nicely.
The same issues apply to a range of function attributes. (Obviously some, such
as "section", make no sense to inline to functions that don't share the same
attribute.) For some attributes, such as "access", inlining disables the
attribute rather than the attribute disabling inlining.
Steadily more code is inlined in modern programming - helped by LTO. Often the
code works the same whether code is inlined or not, with only minor differences
in speed. But in template-heavy C++ code, inlining is essential as you have
large numbers of functions that generate very little (if any) code - failure to
inline as expected can have severe efficiency effects. Conversely, if inlining
disables checking attributes like "access" or "nonnull" the result is a false
sense of security in the programmer.
I think it is important for the manual to be updated to reflect these
limitations as a first step.
Then of course it would be best to remove the limitations!
Ref. mailing list conversation
<https://gcc.gnu.org/pipermail/gcc/2021-June/236592.html> and Martin Sebor's
blog article
<https://developers.redhat.com/articles/2021/06/25/use-source-level-annotations-help-gcc-detect-buffer-overflows>.
(Thanks to Martin for his article and discussion that made me aware of these
points.)
