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

[Philip Reames via llvm-dev]

On 12/11/2015 01:29 PM, James Y Knight wrote:
>
> On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>>         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.
>
>
> It seems a unfortunate, and potentially problematic if llvm doesn't 
> support, at least, "atomicrmw xchg" and "cmpxchg". If you support just 
> those two additionally to load/store, it'll cover everything the C 
> frontend actually needs to be able to do *now* with floating point 
> atomics.
>
> Atomic floating point math isn't actually a supported operation in C 
> now, so it seems reasonable to leave the rest of the atomicrmw ops for 
> a future design.
I'm really not sure what you're trying to say here.  Your two paragraphs 
seem to contradict each other?

For the record, I actually don't care about the C frontend at all. If my 
work helps the clang, great, but that's not my goal.  Others can step up 
to push the changes through clang if they want to see the benefit there.

Philip

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