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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 11 16:24:47 PST 2015


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



More information about the llvm-dev mailing list