On 11/01/2011 12:50 AM, Richard Henderson wrote:
well, the reason for it was so that __atomic_store can be used as a replacement for sync_lock_release on such targets...* optabs.c (expand_atomic_store): Use create_fixed_operand for atomic_store optab. Don't try to fall back to sync_lock_release.--- The create_fixed_operand thinko is obvious. The sync_lock_release is more subtle. The target is allowed to support only storing 0/1 with the test_and_set/lock_release pair, and it's allowed to support that in non-obvious ways. We don't want to get involved in that.
ie, we dont need a different builtin for a target which has only a boolean test and set and clear. Is there harm in allowing that as a fall back? Is there a way of detecting sync_lock_release with those limitations? ie, if there is a lock_release and no compare_and_swap on the target... we could issue it.
Im just concerned that we now lose the ability to implement the boolean class test_and_set and clear now on such a target...
Andrew
