I know that MIPS does that, and an out-of-tree implementation of hexagon
implements 1-byte cmpxchg in terms of the 4-byte version. The emulation
code isn't particularly small, and it seems reasonable to make it a
libcall. The emulation code seems sketchy from a correctness
perspective, as you end up generating unsolicited loads and stores on
adjacent bytes. Take a look at the thread on cfe-dev and llvm-dev named
"the as-if rule / perf vs. security" for some of the ramifications and
concerns surrounding unsolicited loads and stores.
On 3/17/2016 10:05 AM, James Y Knight wrote:
> A 4 byte cmpxchg could be lock free, while a 1 byte cmpxchg may not
be lock free.
That's not possible: if you have a 4-byte cmpxchg instruction, you can
use it to implement a 1-byte cmpxchg, too. Many targets do this
already. (It would be better if that was available generically so that
code didn't need to be written separately fit each target, but that's
not the case at the moment.)
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
