<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 12/11/2015 03:27 PM, James Y Knight
wrote:<br>
</div>
<blockquote
cite="mid:622180C7-527E-47BB-A75E-66AE12A1C464@google.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>
<div class="">On Dec 11, 2015, at 4:55 PM, Philip Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com" class=""><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></a>>
wrote:</div>
<blockquote type="cite" class="">
<div class="">
<meta content="text/html; charset=windows-1252"
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"
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>
</blockquote>
I agree, though, unless reviewers really push for it, I only plan on
implementing the first two for now. I may get to the later at a
future point, but they're not on my must have list right now. <br>
<br>
(Actually, I might get to at least cmpxchg sooner rather than
later. I just noticed we had a bit of code in our frontend hacking
around that too.)<br>
<blockquote
cite="mid:622180C7-527E-47BB-A75E-66AE12A1C464@google.com"
type="cite">
<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>
</blockquote>
Again, I'm not sure what you're getting at. We already support
"atomicrmw add". Did you possible mean "atomicrmw fadd"? Or were
you using "add" in place of "some_other_op_we_dont_yet_support"?<br>
<br>
Philip<br>
<br>
</body>
</html>