public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "david at westcontrol dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/101279] New: Function attributes often block inlining Date: Thu, 01 Jul 2021 08:16:07 +0000 [thread overview] Message-ID: <bug-101279-4@http.gcc.gnu.org/bugzilla/> (raw) 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.)
next reply other threads:[~2021-07-01 8:16 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-01 8:16 david at westcontrol dot com [this message] 2021-07-01 21:30 ` [Bug ipa/101279] " pinskia at gcc dot gnu.org 2021-07-02 0:08 ` msebor at gcc dot gnu.org 2022-06-28 12:20 ` frankhb1989 at gmail dot com 2022-06-28 12:33 ` rguenth at gcc dot gnu.org 2022-06-28 12:53 ` david at westcontrol dot com 2022-06-28 13:25 ` rguenther at suse dot de 2022-06-28 14:20 ` david at westcontrol dot com 2022-06-29 9:07 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-101279-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).