<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 12/11/2015 12:05 AM, JF Bastien
wrote:<br>
</div>
<blockquote
cite="mid:CABdywOd+Sa_3fsM0=5YA1+OUGTAH7KKWezF9hW1wu10ysuhNfg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Dec 11, 2015 at 3:22 AM,
Philip Reames via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<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">Currently,
we limit atomic loads and stores to either pointer or
integer types. I would like to propose that we extend
this to allow both floating point and vector types which
meet the other requirements. (i.e. power-of-two multiple
of 8 bits, and aligned)<br>
</blockquote>
<div><br>
</div>
<div>I support this.</div>
</div>
</div>
</div>
</blockquote>
Great. I'll prepare a patch and send it for review. <br>
<blockquote
cite="mid:CABdywOd+Sa_3fsM0=5YA1+OUGTAH7KKWezF9hW1wu10ysuhNfg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<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">This
will enable a couple of follow on changes:<br>
1) Teaching the vectorizer how to vectorize unordered
atomic loads and stores<br>
2) Removing special casing around type canonicalization of
loads in various passes<br>
3) Removing complexity from language frontends which need
to support atomic operations on floating point types.<br>
</blockquote>
<div><br>
</div>
<div>This may become relevant for C++, see <a
moz-do-not-send="true" href="http://wg21.link/p0020r0"><a class="moz-txt-link-freetext" href="http://wg21.link/p0020r0">http://wg21.link/p0020r0</a></a></div>
<div><br>
</div>
<div><br>
</div>
<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">My
initial implementation plan will not require any changes
from the backends. I plan to add a lowering step to the
existing AtomicExpandPass which will convert atomic
operations on floats and vectors to their equivalently
sized integer counterparts. Over time, individual
backends will be able to opt in - via a TTI hook - to have
the new types of atomics handled by the normal isel
machinery.<br>
<br>
I've prototyped this approach with the x86 backend and get
what looks like correct and even fairly efficient
instruction selection taking place. I haven't studied it
too extensively, so it might not work out in the end, but
the approach appears generally feasible.<br>
</blockquote>
<div><br>
</div>
<div>Simpler path that <a moz-do-not-send="true"
href="http://reviews.llvm.org/D11382">D11382</a>,
generating the same code?</div>
</div>
</div>
</div>
</blockquote>
Actually, I think I was relying on exactly that change. :)<br>
<br>
My initial implementation just converts "store atomic float 0.0,
float* %p unordered, align 4" to<br>
%p.i = bitcast float* %p to i32*<br>
%v = bitcast float 0.0 to i32<br>
store atomic i32 %v, i32* %p.i unordered, align 4<br>
<br>
(i.e. it just does what the frontend previously did in the
AtomicExpand.)<br>
<br>
The net result is that the backend still sees the bitcast idioms you
added pattern matching for. Once that parts in, I'll start changing
the canonical form the backend expects, but given that's backend
specific, I wanted a migration mechanism which worked for all
backends. <br>
<br>
p.s. There's still lots of work to do to improve isel for atomic
loads and stores on these types. I plan to eventually get there,
but my first focus is on a) functional correctness, and b) getting
the middle-end optimizers fixed up. <br>
<blockquote
cite="mid:CABdywOd+Sa_3fsM0=5YA1+OUGTAH7KKWezF9hW1wu10ysuhNfg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<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>
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. <br>
<blockquote
cite="mid:CABdywOd+Sa_3fsM0=5YA1+OUGTAH7KKWezF9hW1wu10ysuhNfg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>This raises similar issues around FP exceptions (are
they impl-defined, UB, unspecified? Do we care?).</div>
</div>
</div>
</div>
</blockquote>
In practice, we seem not to care. This is much broader than my
proposal, and I have no opinions on what the right solutions here
are. <br>
<br>
Philip<br>
<br>
</body>
</html>