Re: Changes in inline behavior on O2 optimization level for GCC 10+

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

In response to

Browse pgsql-hackers by date

  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