<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><div class="">On Dec 11, 2015, at 4:55 PM, Philip Reames <<a href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>> wrote:</div><blockquote type="cite" class=""><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 12/11/2015 01:29 PM, James Y Knight
wrote:<br class="">
</div>
<blockquote cite="mid:CAA2zVHrkLv72AWhFMrvijA=rnymd6x+Hi_e9Ubshfz5kbbO0gA@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra"><br class="">
</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" class=""><<a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org" target="_blank" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">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" class=""><span class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<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 class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</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 class="">
</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>
</blockquote>
I'm really not sure what you're trying to say here. Your two
paragraphs seem to contradict each other?<br class="">
<br class="">
For the record, I actually don't care about the C frontend at all.
If my work helps the clang, great, but that's not my goal. Others
can step up to push the changes through clang if they want to see
the benefit there. <br class=""></div></div></blockquote><br class=""></div><div>I apologize for being unclear.</div><div><br class=""></div><div>I only meant that in C and C++, "atomic_load", "atomic_store", "atomic_exchange", and "atomic_compare_exchange_{weak,strong} are supported for all types, including integers, floats, vectors, aggregates, and pointers. On the other hand the atomic_fetch_{add,sub,and,or,...} operations are not -- they only work on integers and, for "add" and "sub", pointers.</div><div><br class=""></div><div>I think that similarly makes sense in llvm: the instructions "atomic_load", "atomic_store", "atomicrmw xchg", and "cmpxchg" should all support float/vector types of the target-allowed sizes: the mechanism you proposed of adding bitcasts in the AtomicExpandPass should work for all four of those.</div><div><br class=""></div><div>But supporting actual *arithmetic* operations on other types, e.g. "atomicrmw add", "atomicrmw sub", or any of the others, is a completely separate issue, and I don't think it makes any sense to consider that as a part of what you're doing.</div></body></html>