From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Robert Henry <rrh.henry@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: postgres has no spinlock support on riscv rv64imafdc
In-reply-to: <20191019102234.s7utdy44npjqr7in@alap3.anarazel.de>
References: 
 <CAEYr_8nnwxQji0pQJYqFx7=gSM8x7jFJi16O-bLuVYvqvkjsLg@mail.gmail.com>
 <27501.1571382023@sss.pgh.pa.us>
 <20191019102234.s7utdy44npjqr7in@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 19 Oct 2019 03:22:34 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16912.1571545387.1@sss.pgh.pa.us>
Date: Sun, 20 Oct 2019 00:23:07 -0400
Message-ID: <16913.1571545387@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> 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.

Yeah, you could make a similar argument about any sort of compiler
bug ... but gcc has *earned* my lack of trust in this particular area.

			regards, tom lane