[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 13:55:39 PST 2015
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev