Re: Build with LTO / -flto on macOS
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Wolfgang Walther <walther@technowledgy.de>, Peter Eisentraut <peter@eisentraut.org>
Date: 2024-07-19T19:29:07Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make building with LTO work on macOS
- 73275f093f89 18.0 landed
-
Require memory barrier support.
- 83aadbeb96f0 18.0 landed
-
Require compiler barrier support.
- a011dc399cc8 18.0 landed
-
autoconf: Move export_dynamic determination to configure
- 9db49fc5bfdc 16.0 cited
Hi, On 2024-07-19 11:06:47 -0400, Tom Lane wrote: > 2. Do we really want to encourage people to build with -flto? > > I fear that #2 is actually a pretty serious concern. I think there > are a lot of places where we've assumed semi-implicitly that > compilation file boundaries are optimization barriers, particularly > around stuff like LWLocks and semaphores. I don't really want to > spend time chasing obscure, irreproducible bugs that may appear when > that assumption gets broken. I especially don't want to do it just > because some packager has randomly decided to inject random build > switches. I don't really buy this argument. It'd be one thing if compilation boundaries actually provided hard guarantees - but they don't, the CPU can reorder things as well, not just the compiler. And the CPU doesn't know about compilation units. If anything, compiler reorderings are *less* obscure than CPU reordering, because the latter is heavily dependent on running on large enough machines with specific microarchitectures. The only case I know where we do rely on compilation units providing some level of boundaries is on compilers where we don't know how to emit a compiler barrier. That's probably a fallback we ought to remove one of these days... > In short: if we want to support LTO, let's do it officially and not > by the back door. But I think somebody needs to make the case that > there are compelling benefits that would justify the nontrivial > amount of risk and work that may ensue. My default position here > is "sorry, we don't support that". FWIW, I've seen pretty substantial wins, particularly in more heavyweight queries. Greetings, Andres Freund