[LLVMdev] Why can't atomic loads and stores handle floats?

[Philip Reames]

On 05/26/2014 12:51 PM, Tim Northover wrote:
>> There's nothing "wrong" per se with that design, but why
>> complicate a bunch of frontends when a single IR level desugarring pass
>> could preform the same logic?
> I quite like this idea. It could give David his atomic ops where an
> integer really can't do the right thing, and isn't just shunting the
> burden onto all of the backends. Some restrictions would still be
> needed. A "load atomic [1000 x i64]* %addr" is just being cheeky.
>
> The biggest issue I see is modelling the legal loads for a target. For
> example AArch64 probably has "legal" monotonic loads for most sane
> types, in the sense that they can be implemented in the same way as
> non-atomic ones. But there's no "ldar s0, [addr]", and you can't
> simply replace an atomic load with a normal load even in the weaker
> cases because you have no say in what passes run after your shiny
> expansion pass.
>
> With appropriate target hooks, I think it could be made to work.
I'm wiling to take this on.  It's not going to be immediately, but 
cleaning up the code in my frontend is worth the work.

It seems like the logical place for this would either be in CodeGenPrep 
or SelectionDAGBuilder.  Does anyone know of any reason why it would 
need to be done earlier?

I'm going to ignore the generalized transactional-memory use cases for 
the moment.  I want to stick to the subset of features which have fairly 
wide support across platforms.  Honestly, the transactional memory bits 
feel like they should be solved differently anyways.

Philip