Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency

[Jonas Oberhauser]

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