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

[David Chisnall]

On 26 May 2014, at 20:51, Tim Northover <t.p.northover at gmail.com> wrote:

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

Currently, the frontend will have to lower these to calls to the __atomic functions, but there's no technical reason for this on all architectures.  Haswell and newer Intel chips *can* implement atomic loads of 1000 x i64: with the transactional extensions, the limit for loads is very large (the limit for atomic writes is around 30KB).  

As transactional memory becomes more common, large atomicrmw operations become possible, but LLVM IR can't meaningfully express them.  Currently, two architectures in LLVM support hardware transactional memory in some form: x86 and BlueGene/Q.

One of the biggest issues I face implementing the back end for our architecture is the willingness, both in mapping to IR and then to SelectionDAG for LLVM to throw away information that is not yet meaningful to existing back ends.  Let's try not to make that any worse for future back-end authors.  Lots of people are trying to use LLVM for custom ASICs and at EuroLLVM there were a number of people who had encountered similar problems in exactly this.

David