Re: postgres has no spinlock support on riscv rv64imafdc

Merlin Moncure <[email protected]> Fri, 13 Dec 2019 21:26:17 -0600
Newsgroups gmane.comp.db.postgresql.bugs
Message-ID <CAHyXU0zwtb_79=-BPSF5CTLET1cYYBX=EUsNqGDGUWo-6SXdVw@mail.gmail.com>
On Saturday, October 19, 2019, Tom Lane <[email protected]> wrote:

> Andres Freund <[email protected]> writes:
> > On 2019-10-18 09:00:23 +0200, Tom Lane wrote:
> >> TBH, though, my preference would be for some assembly code rather than
> >> relying on GCC builtins as Richard's patch did.
>
> > -1. I think there's good arguments for using inline assembly on
> > platforms where we've done so historically, and where we have to support
> > old compilers without good support for intrinsics/builtins. But I see
> > very little reason for adding more such cases for newer platforms -
> > doing so correctly and efficiently is substantial work and fragile.
>
> The reason I'm skeptical of that line of argument is that gcc's track
> record for support of these intrinsics on non-mainstream architectures
> is just sucky.  Now maybe, somebody was careful and it all works great
> on RISC-V.  But IMO, the burden of proof is to show that the intrinsics
> work, not to show that they don't.
>
> I recall Noah's recent argument in a related context that with an
> asm implementation, anybody with a copy of the architecture manual
> can review/verify the code; and such a verification doesn't depend
> on which compiler version you're using.  If we depend on gcc intrinsics,
> we've basically got zero confidence about anything except from testing.


Do our regression tests exercise the quality of the intrinsic
implementation?

merlin