Am 10/7/2024 um 3:18 PM schrieb David Laight:
From: Jonas Oberhauser
Sent: 07 October 2024 12:55
Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
What _does_ work however are the following two approaches:
1) Perform the equality check on the original variables, creating
new versions (with OPTIMIZER_HIDE_VAR) of both variables for the
rest of their use, therefore making sure the pointer dereference
are not derived from versions of the variables which were compared
with another pointer. (as suggested by Boqun)
This should not be guaranteed to work, because right after the
comparison the compiler can do b=a, then it doesn't matter how much you
hide afterwards.
However it might work if you escape the addresses of a and b first, in
which case the compiler will not do b=a anymore, but it might force the
compiler to put a and b on the stack, which has some performance impact.
Nope, as pointed out last week, the compiler can move the 'a == b'
check to before the OPTIMISER_HID_VAR() and then use the same register
for both of them.
Since the addresses of a and b have escaped, I don't think it can still
put them into the same register (or memory location).
Other threads could be temporarily modifying (inside the escape code) or
concurrently reading (after the escape code) the two variables
independently.
Something in the direction of
a = ...;
...
b = ...;
escape(&a);
escape(&b);
if (a == b) {
OPTIMIZER_HIDE_VAR(b);
*b;
}
Here doing b=a after a==b would (from the point of view of compiler)
potentially introduce a data race.
As I pointed out earlier, the compiler might be able to prove that it is
a benign data race though and theoretically still do b=a. But if you
declare b as volatile on top...
Anyways, the ptr_eq way is much more obvious.
jonas
