On Thu, Oct 27, 2011 at 09:07:29PM -0700, Richard Henderson wrote:
> Jakub, in the seventh patch, is there any good reason why OMP is
> making the decision of whether or not to generate a compare-and-swap
> loop? Why shouldn't we simply always generate the __sync_fetch_op
> builtin and let optabs.c generate the compare-and-swap loop?
It just wants a guarantee that the builtin will actually be implemented
in hw. I guess if __sync_fetch_op (new/old) isn't supported but
__sync_compare_and_swap_* is, we could just use the former and let
optabs.c deal with that. But we have to handle the CAS case anyway
for most of the operations that don't have a __sync_fetch_op defined
(and for the cases where we e.g. VCE floating point data to integer
of the same size for CAS).
For ABI reasons we should keep using GOMP_{start,end}_atomic for the
types that don't have CAS in hw, shouldn't replace it with some generic
C++11 atomic helper in some library (libgcc or elsewhere?).
BTW, I believe all #pragma omp atomic ops we want in the relaxed model
or weaker, I think OpenMP only guarantees that the memory is modified
or loaded atomically (that you don't see half of something and half of
something else), there is nothing that requires ordering the atomic
vs. any other memory location stores/loads.
Jakub
