https://bugs.llvm.org/show_bug.cgi?id=29102
Tim Northover <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Summary|Incorrect barriers for |Incorrect barriers for
|atomic intrinsics on ARM64 |legacy __sync_* on ARM64
Component|new bugs |LLVM Codegen
Resolution|INVALID |---
Product|new-bugs |clang
Assignee|[email protected] |unassignedclangbugs@nondot.
| |org
CC| |[email protected]
--- Comment #3 from Tim Northover <[email protected]> ---
I've just been reading through the Mono history & comments, and it's convinced
me to reopen this.
The issue is specifically with the legacy __sync_* operations. Those *do*
appear to give extra barriers on AArch64 GCC, and the documentation (while
written in horribly vague pre-C++11 terms) could be read to require them -- see
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html.
GCC codegen for a generic loop is roughly:
.L2:
ldxr w1, [x0]
add w1, w1, 4
stlxr w2, w1, [x0]
cbnz w2, .L2
dmb ish
This is also what Will implemented (and justified) in the referenced GCC thread
on the Linux Kernel.
No matter what, this will involve Clang changes. There's a reasonable chance it
could be implemented entirely in Clang (as an "atomicrmw release" followed by a
fence) but I haven't thought in enough detail to convince even myself.
Otherwise it would need the new super_seq_cst above, and also Clang changes to
use it -- so I've put this in the Clang component.
Priority may also be an issue. This requires strong expertise and interest in
the topic. That may be difficult to drum up for legacy intrinsics.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
