From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Remove last traces of HPPA support |
Date: | 2024-07-29 21:50:08 |
Message-ID: | CA+hUKGKAf_i6w7hB_3pqZXQeqn+ixvY+CMps_n=mJ5HAatMjMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 3, 2024 at 8:09 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Here are some experimental patches to try out some ideas mentioned
> > upthread, that are approximately unlocked by that cleanup.
>
> FWIW, I'm good with getting rid of --disable-spinlocks and
> --disable-atomics. That's a fair amount of code and needing to
> support it causes problems, as you say. I am very much less
> excited about ripping out our spinlock and/or atomics code in favor
> of <stdatomic.h>; I just don't see the gain there, and I do see risk
> in ceding control of the semantics and performance of those
> primitives.
OK, <stdatomic.h> part on ice for now. Here's an update of the rest,
this time also removing the barrier fallbacks as discussed in the LTO
thread[1].
I guess we should also consider reimplementing the spinlock on the
atomic API, but I can see that Andres is poking at spinlock code right
now so I'll keep out of his way...
Side issue: I noticed via CI failure when I tried to require
read/write barriers to be provided (a choice I backed out of), that on
MSVC we seem to be using the full memory barrier fallback for those.
Huh? For x86, I think they should be using pg_compiler_barrier() (no
code gen, just prevent reordering), not pg_pg_memory_barrier(), no?
Perhaps I'm missing something but I suspect we might be failing to
include arch-x86.h on that compiler when we should... maybe it needs
to detect _M_AMD64 too? For ARM, from a quick look, the only way to
reach real acquire/release barriers seems to be to use the C11
interface (which would also be fine on x86 where it should degrade to
a no-op compiler barrier or signal fence as the standard calls it),
but IIRC the Windows/ARM basics haven't gone in yet anyway.
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Remove-disable-spinlocks.patch | text/x-patch | 27.8 KB |
v2-0002-Remove-disable-atomics-require-32-bit-atomics.patch | text/x-patch | 20.3 KB |
v2-0003-Require-compiler-barrier-support.patch | text/x-patch | 2.8 KB |
v2-0004-Require-memory-barrier-support.patch | text/x-patch | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2024-07-29 21:59:57 | Re: Optimize mul_var() for var1ndigits >= 8 |
Previous Message | Masahiko Sawada | 2024-07-29 21:25:11 | Re: xid_wraparound tests intermittent failure. |