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

[Hal Finkel via llvm-dev]

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