|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Cleaning up historical portability baggage|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> I see that prairiedog was the only buildfarm animal failing the
> HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
> there are any assemblers remaining in the wild that can't parse that.
Actually, after further investigation and testing, I think we could
drop the conditionality around PPC spinlock sequences altogether.
The commentary in pg_config_manual.h claims that "some pre-POWER4
machines" will fail on LWSYNC or LWARX with hint, but I've now
confirmed that the oldest PPC chips in my possession (prairiedog's
ppc7400, as well as a couple of ppc7450 machines) are all fine with
both. Indeed, prairiedog would have been failing for some time now
if it didn't like LWSYNC, because port/atomics/arch-ppc.h is using
that unconditionally in some places :-(. I think we can safely
assume that such machines no longer exist in the wild, or at least
are not going to be used to run Postgres v16.
The attached, expanded patch hard-wires USE_PPC_LWARX_MUTEX_HINT
and USE_PPC_LWSYNC as true, and syncs the assembler sequences in
arch-ppc.h with that decision. I've checked this lightly on
tern's host as well as my own machines.
regards, tom lane
|Next Message||Thomas Munro||2022-08-12 21:48:24||Re: Cleaning up historical portability baggage|
|Previous Message||David G. Johnston||2022-08-12 19:58:28||Re: doc: New cumulative stats subsystem obsoletes comment in maintenance.sgml|