H. Peter Anvin <hpa@xxxxxxxxx> wrote: > Well, that sounds promising. I wonder how David's model, using > intrinsics (do we have enough intrinsics to actually be able to do this > "correctly"?), compare to using the flags output from assembly. There is an advantage to using the intriniscs on arches with explicit barriers. On powerpc64, for example, the compiler can move the release memory barrier earlier to push register-only instructions between the barrier and the lwarx. This would allow the memory barrier to be executed concurrently with those instructions. The compiler could also move the acquire memory barrier later, pulling register-only instructions between the stwcx and that barrier, though I don't see any advantage to doing so. Whereas if the release barrier is in the same asm block as the lwarx, the compiler cannot do anything with it. Another advantage is that the compiler can switch between instruction variants automatically, allowing us to get rid of the size-based switch statements for things like cmpxchg(). However, there's probably not a great deal of difference to be had if the inline asm codes the appropriate instruction in each case for something like x86*. The emitted code ought to look the same. The second biggest win for the intriniscs, I think, is the ability to ask the CMPXCHG instruction whether it actually did anything rather than comparing the result. I added two variants, one that only returned the yes/no and one that passed back the value as well as the yes/no. David -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
