From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alexey Makhmutov <a(dot)makhmutov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Changes in inline behavior on O2 optimization level for GCC 10+ |
Date: | 2025-07-28 18:27:40 |
Message-ID: | CAH2-Wz=7u=pD=jrQON3KEjUf=aYhA4V7mNB5Z_630XfFNZHQwA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 27, 2025 at 5:48 PM Alexey Makhmutov
<a(dot)makhmutov(at)postgrespro(dot)ru> wrote:
> The primary goal of this message is just to raise an awareness of this
> change and its possible influence on resulting builds.
I believe that clang works in the same way, and has for some time now.
"clang -mllvm -debug" output shows debug instrumentation that can
demonstrate that clang may inline functions that are not declared
"static inline" (and decline to inline functions that are). As I
understand it, to clang, the "inline" directive just lowers the
threshold at which a function will be inlined.
> Theoretically speaking, this change is not an issue by itself, as each
> compiler is in its right to adjust its optimization logic. Certain build
> pipeline could always have adjusted parameters if its maintainer is
> unsatisfied with default compiler heuristics.
"pg_attribute_always_inline" can be used to force the compiler to
inline a function. I'd be very surprised if GCC 10 failed to honor the
underlying "__attribute__((always_inline))" function attribute.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-28 18:28:43 | Re: Regression with large XML data input |
Previous Message | Jacob Champion | 2025-07-28 18:20:09 | Re: Explicitly enable meson features in CI |