Re: [PATCH] Native spinlock support on RISC-V

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2021-08-13 13:37:02 -0400, Tom Lane wrote:
>> so it seems like someday we might want to expend some effort on native
>> atomics. I agree that that day need not be today, though. This patch
>> seems sufficient until we get to the point of (at least) having some
>> RISC-V in the buildfarm.

> Gcc's intriniscs are pretty good these days (and if not, a *lot* of
> projects just outright break).
> What's more, It turns out that using intrinsics with compilers of the
> last ~5 years often generates *better* code than inline assembly
> (e.g. because the compiler can utilize condition codes more effectively
> and has more detailed information about clobbers). So for new platforms
> that'll only have support by new compilers it doesn't really make sense
> to add inline assembler imo.

I didn't say it had to be __asm blocks ;-). I was thinking more of the
sort of stuff we have in e.g. arch-arm.h and arch-ia64.h, where we know
some things about what is efficient or less efficient on a particular
architecture. gcc will do its best to provide implementations of
its builtins, but that doesn't mean that using a particular one of
them is always the most sane thing to do.

But anyway, that seems like minor optimization that maybe someday
somebody will be motivated to do. We're on the same page about this
being enough for today.

I did not like confusing the RISC-V case with the ARM case: duplicating
the code block seems better, in case there's ever reason to add
arch-specific stuff like SPIN_DELAY. So I split it off to its own
code block and pushed it.

regards, tom lane