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~