Re: Build with LTO / -flto on macOS

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
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:56:03
Message-ID: 20240719195603.rxqdfm35uqvx2ndw@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> >> 2. Do we really want to encourage people to build with -flto?
>
> > 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...
>
> Hm. We've moved our platform/toolchain goalposts far enough in the
> last few releases that that might not be too big a lift. Do you
> know offhand which supported platforms still have a problem there?
>
> (mumble AIX mumble)

In 16 it looks like the only case might indeed have been [drumroll] AIX with
xlc (with gcc . And there it it looks like it'd have been trivial to implement
[1].

We've been talking about requiring 32 bit atomics and a spinlock
implementation - this imo fits in well with that, without proper barriers it's
pretty much impossible to have correct spinlocks and, even more so, any lock
free construct, of which we have a bunch.

IOW, let's rip out the fallback implementation for compiler and memory
barriers and fix the fallout, if there is any.

Greetings,

Andres Freund

[1] I think it'd just be __fence(). Looks like it's been present for a while,
found it in "IBM XL C/C++ for AIX, V10.1 Compiler Reference Version 10.1",
which looks to be from 2008.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2024-07-19 20:00:46 Re: documentation structure
Previous Message Tomas Vondra 2024-07-19 19:48:10 Re: Report search_path value back to the client.