Re: Nixing __HAVE_ATOMIC_AS_MEMBAR

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 22 Feb 2023 12:57:24 +0000
> From: Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>
> 
> I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it
> is a bad API, and replace it by one of two options:
> 
> (a) Add membar_release_preatomic and membar_acquire_postatomic: noop
>     if __HAVE_ATOMIC_AS_MEMBAR, alias for membar_release/acquire
>     otherwise.
> [...]
> (b) Change the semantics of membar_release and membar_acquire so they
>     are noops on platforms with __HAVE_ATOMIC_AS_MEMBAR, like x86.
>     For ordering plain loads and stores there are still
>     atomic_load_acquire and atomic_store_release.

A third option occurred to me this evening:

(c) Just make the membars unconditional -- take off the #ifndefs, but
    don't add any new functions or change the semantics of existing
    ones.

    This would only hurt on platforms where __HAVE_ATOMIC_AS_MEMBAR
    could be set (x86 and sparc/sparc64, to my knowledge, though only
    x86 actually does set it) but that don't run in Total Store Order
    (which x86 does and, as far as I'm aware, all real sparc/sparc64
    hardware on the planet does too).

    In other words, except perhaps for adding a trivial procedure call
    on x86, it would have no performance impact on any architectures
    in NetBSD, let alone any architectures I know about.  We could
    also make membar_* be macros expanding to __insn_barrier on x86 to
    avoid the procedure call overhead.

The micro-optimization of __HAVE_ATOMIC_AS_MEMBAR presumably arose in
the first place at a time when the x86 membar_* did needless extra
work like LOCK ADD, LFENCE, MFENCE, or SFENCE, none of which are
needed in TSO except by membar_sync.  Now that x86 membar_* are
correctly reduced to noops (except membar_sync) perhaps there's no
longer any need for this.