public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dani at danielbertalan dot dev" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/114784] New: [14 Regression] Inlining fails for always_inline inheriting constructor Date: Fri, 19 Apr 2024 20:05:49 +0000 [thread overview] Message-ID: <bug-114784-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784 Bug ID: 114784 Summary: [14 Regression] Inlining fails for always_inline inheriting constructor Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: dani at danielbertalan dot dev Target Milestone: --- The code below has been reduced from SerenityOS's custom std::variant-like type. Its constructors are implemented by recursively inheriting from a helper class which adds a constructor that can take one of the stored types. This, however, creates a bunch of small constructors - each of which just end up calling into the set<T>() method - which don't necessarily get inlined. Our measurements showed that we can achieve up to 20% reduction in the run time of our test suite by marking these as __attribute__((always_inline)). (Like in most other similar issues, inlining is not a matter of correctness for us, we just want to overrule inlining heuristics). Ever since the GCC trunk of summer 2023, we have been getting compile errors about failing to inline these constructors ("call is unlikely and code size would grow"). Below is the smallest reproducer we could create for this issue (admittedly, it has UB, so not sure if it's the exact same issue as in the real code). Note that if we explicitly write out the constructor instead of inheriting it (even if it does the same thing), as shown by the long long overloads below, the issue goes away (compile with -std=c++20 -O2). See: https://godbolt.org/z/5hb584T9r --- template <typename Base> struct VariantConstructors { __attribute__((always_inline)) VariantConstructors(int t) { base().set(t, {}); } __attribute__((always_inline)) VariantConstructors(long long t) { base().set(t, {}); } Base base(); }; struct Variant : VariantConstructors<Variant> { using VariantConstructors<Variant>::VariantConstructors; __attribute__((always_inline)) Variant(long long v) : VariantConstructors(v) {} template <typename T> void set(T &&, int); char m_data; }; struct ErrorOr { ErrorOr(int v) : a(v) { } ErrorOr(long long v) : a(v) { } Variant a; }; static ErrorOr run() { ErrorOr x(0); // compiles with this line removed ErrorOr y(0LL); return 0; } int serenity_main() { run(); } --- gcc -v output: GNU C++20 (Compiler-Explorer-Build-gcc-85c187b2127b937e211dfe46b4120d320ff661df-binutils-2.40) version 14.0.1 20240419 (experimental) (x86_64-linux-gnu) compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
next reply other threads:[~2024-04-19 20:05 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-19 20:05 dani at danielbertalan dot dev [this message] 2024-04-19 20:08 ` [Bug ipa/114784] " dani at danielbertalan dot dev 2024-04-19 20:21 ` jakub at gcc dot gnu.org 2024-04-19 20:42 ` jakub at gcc dot gnu.org 2024-04-19 21:07 ` jakub at gcc dot gnu.org 2024-04-19 22:00 ` dani at danielbertalan dot dev 2024-04-22 11:14 ` jakub at gcc dot gnu.org 2024-04-23 6:39 ` cvs-commit at gcc dot gnu.org 2024-04-23 6:40 ` jakub 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-114784-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).