[llvm-bugs] [Bug 51435] New: Missed optimization for Atomic load
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Aug 10 12:06:30 PDT 2021
https://bugs.llvm.org/show_bug.cgi?id=51435
Bug ID: 51435
Summary: Missed optimization for Atomic load
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: shivam98.tkg at gmail.com
CC: llvm-bugs at lists.llvm.org
Hi,
Please consider the below test case.
struct Foo {
unsigned *ptr = nullptr;
bool cond = true;
unsigned a1 = 0;
unsigned a2 = 0;
unsigned foo();
};
unsigned Foo::foo() {
unsigned oldest_snapshot;
if (!ptr) {
oldest_snapshot = cond
? __atomic_load_n(&a1, __ATOMIC_ACQUIRE)
: __atomic_load_n(&a2, __ATOMIC_ACQUIRE);
} else {
oldest_snapshot = *ptr;
}
return oldest_snapshot;
}
X86 issue:
clang++ test.cc -O1 -g -c && llvm-objdump -d test.o
0000000000000000 <_ZN3Foo3fooEv>:
0: 48 8b 07 mov (%rdi),%rax
3: 48 85 c0 test %rax,%rax
6: 74 03 je b <_ZN3Foo3fooEv+0xb>
8: 8b 00 mov (%rax),%eax
a: c3 retq
b: 80 7f 08 00 cmpb $0x0,0x8(%rdi)
f: 74 09 je 1a <_ZN3Foo3fooEv+0x1a>
11: 8b 47 0c mov 0xc(%rdi),%eax
14: 48 83 c7 0c add $0xc,%rdi
18: eb 07 jmp 21 <_ZN3Foo3fooEv+0x21>
1a: 8b 47 10 mov 0x10(%rdi),%eax
1d: 48 83 c7 10 add $0x10,%rdi
21: 48 89 f8 mov %rdi,%rax
24: 8b 00 mov (%rax),%eax
26: c3 retq
1a-21 is the atomic load, whose result is discarded then 24 is a duplicate
non-atomic load instructions, 1a-21 are pointless.
aarch64 issue:
$ clang++ --target=aarch64 test.cc -O1 -g -c && llvm-objdump -d test.o
0000000000000000 <_ZN3Foo3fooEv>:
0: f9400008 ldr x8, [x0]
4: b4000068 cbz x8, 10 <_ZN3Foo3fooEv+0x10>
8: b9400100 ldr w0, [x8]
c: d65f03c0 ret
10: 39402008 ldrb w8, [x0, #8]
14: 34000068 cbz w8, 20 <_ZN3Foo3fooEv+0x20>
18: 91003008 add x8, x0, #0xc
1c: 14000002 b 24 <_ZN3Foo3fooEv+0x24>
20: 91004008 add x8, x0, #0x10
24: 88dffd1f ldar wzr, [x8]
28: b9400100 ldr w0, [x8]
2c: d65f03c0 ret
The same load duplication, but we can see that the first one is atomic-acquire,
but the second one misses the acquire part. This can lead to arbitrary memory
corruption.
Please let me know bug reporting needs to improve.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210810/0ba355ef/attachment.html>
More information about the llvm-bugs
mailing list