Hi Eli, > The obvious objection is that the definition of these intrinsics is > basically "this intrinsic has undefined behavior".
I think that's rather pessimistic, though I can see how my warning could have given that impression. In practice I believe CPUs implement the exclusive monitors at the level of the cache line, and "unrelated" loads and stores are not allowed to interfere by the specification. On a CPU like this, the only way LLVM could interfere would be with a spill to a stack slot on the same cache line as the atomic variable being accessed. I think that leaves a large segment of uses which are guaranteed to work: put your ldrexed variables somewhere other than the stack and either make sure they're alone on their cache line or don't store to any others nearby between the ldrex and strex. Navigating that space might be tricky, but given that the alternative in use now is inline assembly, we can probably assume some degree of competence for the users of these intrinsics. Also, these already exist in other compilers (and ours!) which make no more guarantees than we do as far as I'm aware. That doesn't necessarily mean we should follow, but it might suggest the issues are surmountable. Cheers. Tim. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
