[jmm-dev] Jmm revision status
Francesco Zappa Nardelli
francesco.zappa_nardelli at inria.fr
Sat Jul 19 08:52:05 UTC 2014
>> 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.
More information about the jmm-dev