[jmm-dev] Jmm revision status

[Francesco Zappa Nardelli]

>> For C, if we look only at existing implementations, it seems that the only
>> cost is prohibiting some compiler transformations on relaxed operations, and
>> the cost on 64-bit ARMv8.  The former seems trivial; I suspect most
>> compilers don't reorder atomic accesses anyway.
> 
> For the optimisation cost, I think Francesco et al. are starting to
> see optimisations involving atomics, but I agree that for relaxed
> there shouldn't (in principle) be much cost from forbidding them.

For what it is worth, we have observed:

- reorderings of non-atomic accesses with relaxed atomic accesses on clang

- reorderings of non-atomic accesses with atomic accesses on gcc

- eliminations of non-atomic accesses across atomic accesses on gcc (should double check)

We have not observed optimisations involving only atomic accesses (eg reordering two atomic accesses).  The situation evolved a bit wrt last year, when we could not observe any of these. 

-francesco