This exposed a wealth of problems in code that has heretofore never
been tested. The fourth patch makes certain that all expansions of
compare-and-swap go through a single routine.
I've tested the whole series with and without the last patch. So
that I've tested both the sync_ and atomic_ paths. I've not attempted
to test if both are present. I rather assume that'll never be the
case for any target.
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?
I'm going to commit this to the branch, but an extra set of eyes
looking at the sync.md changes.
r~
Richard Henderson (9):
Fix thinko in gen_mem_thread_fence operand.
Handle expanding insns with 8 operands.
Introduce and use can_compare_and_swap_p.
Rewrite all compare-and-swap in terms of
expand_atomic_compare_and_swap.
Add missing atomic optab initializations.
Update cppbuiltins for atomic-compare-and-swap.
Update omp for new atomic optabs.
Convert i386 backend to new atomic patterns.
Update ChangeLogs.
gcc/ChangeLog.mm | 58 ++++++
gcc/builtins.c | 53 ++++--
gcc/c-family/ChangeLog.mm | 4 +
gcc/c-family/c-cppbuiltin.c | 50 ++++--
gcc/config/i386/i386.md | 5 +-
gcc/config/i386/sync.md | 306 +++++++++++++++++---------------
gcc/expr.h | 4 -
gcc/genopinit.c | 6 +
gcc/omp-low.c | 58 +++---
gcc/optabs.c | 422 +++++++++++++++++--------------------------
gcc/optabs.h | 20 ++
11 files changed, 515 insertions(+), 471 deletions(-)
--
1.7.6.4
