[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types

[JF Bastien via llvm-dev]

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>