On 7/9/25 11:53 PM, Sebastian Huber wrote:
There are targets, which only offer 32-bit atomic operations (for
example 32-bit RISC-V). For these targets, split the 64-bit atomic
bitwise-or operation into two parts.
For this test case
int a(int i);
int b(int i);
int f(int i)
{
if (i) {
return a(i);
} else {
return b(i);
}
}
with options
-O2 -fprofile-update=atomic -fcondition-coverage
the code generation to 64-bit vs. 32-bit RISC-V looks like:
addi a5,a5,%lo(.LANCHOR0)
beq a0,zero,.L2
li a4,1
- amoor.d zero,a4,0(a5)
- addi a5,a5,8
- amoor.d zero,zero,0(a5)
+ amoor.w zero,a4,0(a5)
+ addi a4,a5,4
+ amoor.w zero,zero,0(a4)
+ addi a4,a5,8
+ amoor.w zero,zero,0(a4)
+ addi a5,a5,12
+ amoor.w zero,zero,0(a5)
tail a
.L2:
- amoor.d zero,zero,0(a5)
+ amoor.w zero,zero,0(a5)
+ addi a4,a5,4
+ amoor.w zero,zero,0(a4)
li a4,1
- addi a5,a5,8
- amoor.d zero,a4,0(a5)
+ addi a3,a5,8
+ amoor.w zero,a4,0(a3)
+ addi a5,a5,12
+ amoor.w zero,zero,0(a5)
tail b
Not related to this patch, even with -O2 the compiler generates
no-operations like
amoor.d zero,zero,0(a5)
and
amoor.w zero,zero,0(a5)
Would this be possible to filter out in instrument_decisions()?
Just to touch on the last issue. We don't generally try that hard to
optimize atomics, so I'm not terribly surprised to see that kind of dumb
code.
If you've got a testcase for the nop-atomics, definitely get it filed as
a bug. My worry with those cases is we may not have the semantics
exposed in RTL to allow for optimization, though it's more likely we
have them in gimple.
Jeff
