llvm dev - Dec 2015 - RFC: Extending atomic loads and stores to floating point and vector types

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)

This will enable a couple of follow on changes:
1) Teaching the vectorizer how to vectorize unordered atomic loads and 
stores
2) Removing special casing around type canonicalization of loads in 
various passes
3) Removing complexity from language frontends which need to support 
atomic operations on floating point types.

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.

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.

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?

Philip

On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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)
>
I support this.


This will enable a couple of follow on changes:
> 1) Teaching the vectorizer how to vectorize unordered atomic loads and
> stores
> 2) Removing special casing around type canonicalization of loads in
> various passes
> 3) Removing complexity from language frontends which need to support
> atomic operations on floating point types.
>
This may become relevant for C++, see http://wg21.link/p0020r0


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.
>
> 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.
>
Simpler path that D11382 <http://reviews.llvm.org/D11382>, generating the
same code?


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?
>
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.

This raises similar issues around FP exceptions (are they impl-defined, UB,
unspecified? Do we care?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/07fc62a6/attachment.html>

Hi Philip,

I think this makes sense.

 -Hal

----- Original Message -----
> From: "Philip Reames via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 10, 2015 8:22:22 PM
> Subject: [llvm-dev] RFC: Extending atomic loads and stores to floating
point and vector types
> 
> 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)
> 
> This will enable a couple of follow on changes:
> 1) Teaching the vectorizer how to vectorize unordered atomic loads
> and
> stores
> 2) Removing special casing around type canonicalization of loads in
> various passes
> 3) Removing complexity from language frontends which need to support
> atomic operations on floating point types.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> Philip
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 12/11/2015 12:05 AM, JF Bastien wrote:
> On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     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)
>
>
> I support this.
Great.  I'll prepare a patch and send it for review.
>
>
>     This will enable a couple of follow on changes:
>     1) Teaching the vectorizer how to vectorize unordered atomic loads
>     and stores
>     2) Removing special casing around type canonicalization of loads
>     in various passes
>     3) Removing complexity from language frontends which need to
>     support atomic operations on floating point types.
>
>
> This may become relevant for C++, see http://wg21.link/p0020r0
>
>
>     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.
>
>     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.
>
>
> Simpler path that D11382 <http://reviews.llvm.org/D11382>, generating
> the same code?
Actually, I think I was relying on exactly that change.  :)

My initial implementation just converts "store atomic float 0.0, float* 
%p unordered, align 4" to
%p.i = bitcast float* %p to i32*
%v = bitcast float 0.0 to i32
store atomic i32 %v, i32* %p.i unordered, align 4

(i.e. it just does what the frontend previously did in the AtomicExpand.)

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.

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.
>
>
>     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?
>
>
> 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.
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.
>
> This raises similar issues around FP exceptions (are they 
> impl-defined, UB, unspecified? Do we care?).
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.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/f6597d96/attachment.html>

Patch posted for review: http://reviews.llvm.org/D15471

Philip

On 12/10/2015 06:22 PM, Philip Reames wrote:
> 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)
>
> This will enable a couple of follow on changes:
> 1) Teaching the vectorizer how to vectorize unordered atomic loads and 
> stores
> 2) Removing special casing around type canonicalization of loads in 
> various passes
> 3) Removing complexity from language frontends which need to support 
> atomic operations on floating point types.
>
> 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.
>
> 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.
>
> 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?
>
> Philip
>
>
>

On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames <listmail at
philipreames.com>
wrote:
> Patch posted for review: http://reviews.llvm.org/D15471

Looking at the patch, I think we should do FP only for now as vectors have
extra complexities which IMO warrant more discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151212/7a61bdef/attachment.html>

Hi Philip,
> On 11 Dec 2015, at 02:22, Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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)
If you’re adding support for floating point atomics, would it be possible for
you to add support for atomic operations on pointers too?  Currently, front ends
need to bitcast pointers to an integer type which assumes that a corresponding
integer type exists (it doesn’t for us) and loses pointerness of the operand in
the middle, making life annoying for garbage collection.

David

On 12/13/2015 01:03 PM, David Chisnall wrote:
> Hi Philip,
>
>> On 11 Dec 2015, at 02:22, Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> 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)
> If you’re adding support for floating point atomics, would it be possible
for you to add support for atomic operations on pointers too?  Currently, front
ends need to bitcast pointers to an integer type which assumes that a
corresponding integer type exists (it doesn’t for us) and loses pointerness of
the operand in the middle, making life annoying for garbage collection.
Currently, our support for atomics on pointers is mixed.  Atomic loads 
and stores of pointer types are supported.  atomicrmw and cmpxchg 
operations on pointers not.  I know of no reason for the distinction.

I agree that making the change you're proposing is valuable.  If you 
want to file a bug and assign it me, I'll likely get to it in the next 
couple of weeks. Alternatively, I'd be happy to review patches. 
:)
>
> David
>