Re: postgres has no spinlock support on riscv rv64imafdc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Henry <rrh(dot)henry(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: postgres has no spinlock support on riscv rv64imafdc
Date: 2019-10-20 04:23:07
Message-ID: 16913.1571545387@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-10-20 08:58:17 BUG #16070: A double-free bug in interfaces/libpq/fe-secure-openssl.c
Previous Message Eric Toombs 2019-10-20 03:51:44 Re: BUG #16065: The operation nodes in query plans outputted by EXPLAIN have no authoritative definitions.