On 8/13/25 9:00 PM, Sebastian Huber wrote:
Hello Jeff,
thanks for your comment.
----- Am 10. Jul 2025 um 16:01 schrieb Jeff Law jeffreya...@gmail.com:
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
So looking at this again, this is sufficient to show some of the issues.
I would file this as a bug. I think the question will turn into
whether or not we want the instrumentation code to try and optimize away
unnecessary ops or if it should be left to the gimple optimizers.
In the opptimized dump we can see stuff like this:
__atomic_fetch_or_8 (&__gcov8.f[1], 0, 0);
So that's not going to change the value at &__gcov8.f[1] and we don't
use the result, so we don't actually need to do the load either. So
this could in theory just be removed at the gimple phase. Or at least
that's how it seems to me.
jeff
