On 10/28/2011 04:06 AM, Jakub Jelinek wrote:
> 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).

I was just thinking that the data structure with the 6 optabs that we're
exporting from optabs.c is somewhat over the top, when simply testing
can_compare_and_swap_p is just about equivalent.

On reflection, I think I'll revert that patch and try it with just that
one test...

> 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.

... possibly with switching to the new builtins in relaxed mode?


r~

Reply via email to