Horton

Re: Build with LTO / -flto on macOS

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-19T21:04:53Z
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 →

  1. Make building with LTO work on macOS

  2. Require memory barrier support.

  3. Require compiler barrier support.

  4. autoconf: Move export_dynamic determination to configure

On Sat, Jul 20, 2024 at 7:56 AM Andres Freund <andres@anarazel.de> wrote:
> On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.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.

I'll incorporate that into the next version of:

https://www.postgresql.org/message-id/flat/3351991.1697728588%40sss.pgh.pa.us

... with a view to committing in the next few days.

(Ignore the <stdatomic.h> patch, that's just an experiment for now,
but it's not part of what I plan to commit.)