__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Alexander Monakov]

On Thu, 29 Jun 2017, Alexander Monakov wrote:
> (but of course that's a nontrivial amount of work for a somewhat "academic"
> issue)

I think a practical approach is to give the user a degree of control by
introducing a tri-state compiler option controlling how double-word atomics
are to be emitted:

- -m128-bit-atomics=libcalls

  this is the current behavior, all doubleword atomics become libatomic API
  calls; I don't imagine anyone really likes that;

- -m128-bit-atomics=cas+loads

  all doubleword atomics, including loads, become cas/ll-sc loops; atomic loads
  from readonly memory may trap, but the user may know that their code never
  encounters that situation (e.g. if it's in control of how atomic objects are
  allocated, normally on stack or on heap);

  it would be binary-incompatible with the above option, but, again, acceptable
  in many situations where the atomic objects are not exposed to
  potentially-incompatible code;

  I think this is what users would actually want in practice;

- -m128-bit-atomics=cas-loads

  all doubleword atomics, *exluding loads*, become cas/ll-sc loops; atomic loads
  become calls; in the end the user gets a link error and needs to decide how to
  handle it:
  - either adjust the program such that no plain loads remain, or
  - resolve the link error by providing a definition that works via cas, if they
    know that their accesses won't trap (could be with a static inline function,
    so in the end there's no overhead),
  - use the solution with kernel+vdso assist from the previous mail :)

  this might eventually become the default compiler behavior.

Alexander