RFC: Extending atomic loads and stores to floating point and vector types

Project Infrastructure LLVM Dev List Archives
21

Do they end up using the same lock though? If not, we’d still have a race and break atomicity. Also, what about the case of partially overlapping accesses? The code you linked to seems to only handle the case where the base and size of the access regions match exactly. Philip

22

   - Once we add vector, should we consider adding other composite
   types in general, including structs? C++ allows this, but has substantial
   issues w.r.t. padding.

I'd say possibly, but FCAs are poorly supported in the IR in general.
I am not willing to block changes for vectors on changes for FCAs. This
has never been our policy in the past and should not become so now.

Oh yeah I don't think we should block it. FWIW I expect that some of
these will generate calls to the runtime's global atomic lock shard, which
is horrible.

"global atomic lock shard"? I have no idea what you're referring to.
Is that something in libc?

compiler-rt:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c

Hm, I think this raises an interesting semantic question. We could use
the global lock shard scheme to make loads atomic w.r.t. other llvm emitted
writes, but not writes emitted by other compilers. This would mean that
linking object files with atomics might break their atomicity. I'm not
sure we want to allow that. Maybe we can do that only if the
synchronization scope allows it or something?

GCC does it in libatomic:
https://github.com/gcc-mirror/gcc/tree/master/libatomic

They agree on the function name, so AFAIK either runtime allows this to
work properly: the compiler just emits a call to the function, and one of
the runtimes has to be present.

Do they end up using the same lock though? If not, we'd still have a race
and break atomicity.

I believe this is the intent.

Also, what about the case of partially overlapping accesses? The code you

linked to seems to only handle the case where the base and size of the
access regions match exactly.

That would be UB :slight_smile:

23

Here are some gcc docs describing inlining atomics vs. making library calls. The intro explicitly covers inter-compiler compatibility.
https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary

_______________________________________________
LLVM Developers mailing list
[llvm-dev@lists.llvm.org](mailto:llvm-dev@lists.llvm.org)
[http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev](http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev)