<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 17, 2016 at 12:55 PM, Craig, Ben <span dir="ltr"><<a href="mailto:ben.craig@codeaurora.org" target="_blank">ben.craig@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote><div><br></div><div>That's fine. Either do it inline or via an out-of-line version of the same code, in a libcall. Either way acts the same, that is something that the target backend can decide to do whenever it wants.</div><div><br></div><div>The important property for Clang is that it know whether it's lock-free or not. And I don't believe there's any reason to use a mutex to implement a 1-byte ,cmpxchg on a platform with a 4-byte cmpxchg instruction available.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  The emulation code seems sketchy from a correctness perspective, as you end up generating unsolicited loads and stores on adjacent bytes.</blockquote><div><br>I disagree. I do not see how expanding a subword cmpxchg into a word-size-and-aligned cmpxchg could possibly cause a problem.</div></div></div></div>