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

             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: link
Be 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).