From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Wolfgang Walther <walther(at)technowledgy(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Subject: | Re: Build with LTO / -flto on macOS |
Date: | 2024-07-19 19:29:07 |
Message-ID: | 20240719192907.5toy7df3d3q5oy7g@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2024-07-19 19:34:56 | Re: Enhance pg_dump multi-threaded streaming (WAS: Re: filesystem full during vacuum - space recovery issues) |
Previous Message | David E. Wheeler | 2024-07-19 19:27:49 | DSO Terms Galore |