<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One
              open question I don't know the answer to: Are there any
              special semantics required from floating point stores
              which aren't met by simply bitcasting their result to i32
              (float) or i64 (double) and storing the result?  In
              particular, I'm unsure of the semantics around
              canonicalization here.  Are there any? Same for loads?<br>
            </blockquote>
            <div><br>
            </div>
            <div>I'd go a bit further: should you also support basic FP
              operations atomically? The above C++ paper adds add/sub,
              and we've discussed adding FMA as well.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Just to be clear, I assume you mean extending the atomicrmw, and
    cmpxchg instructions right?  I agree this is worth doing, but I'm
    purposely separating that into a possible later proposal.  I don't
    need this right now and keeping the work scoped reasonably is key to
    making progress.  </div></blockquote><div><br></div><div class="gmail_extra">It seems a unfortunate, and potentially problematic if llvm doesn't support, at least, "atomicrmw xchg" and "cmpxchg". If you support just those two additionally to load/store, it'll cover everything the C frontend actually needs to be able to do *now* with floating point atomics.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Atomic floating point math isn't actually a supported operation in C now, so it seems reasonable to leave the rest of the atomicrmw ops for a future design.</div></div></div></div>