On Tue, Jun 21, 2022 at 01:59:27PM +0200, Paul Heidekrüger wrote:
> OK. So, LKMM limits the scope of control dependencies to its arm(s), hence
> there is a control dependency from the last READ_ONCE() before the loop
> exists to the WRITE_ONCE().
>
> But then what about the following:
>
> > int *x, *y;
> >
> > int foo()
> > {
> > /* More code */
> >
> > if(READ_ONCE(x))
> > return 42;
> >
> > /* More code */
> >
> > WRITE_ONCE(y, 42);
> >
> > /* More code */
> >
> > return 0;
> > }
>
> The READ_ONCE() determines whether the WRITE_ONCE() will be executed at all,
> but the WRITE_ONCE() doesn't lie in the if condition's arm.
So in this case the LKMM would not recognize that there's a control
dependency, even though it clearly exists.
> However, by
> "inverting" the if, we get the following equivalent code:
>
> > if(!READ_ONCE(x)) {
> > /* More code */
> >
> > WRITE_ONCE(y, 42);
> >
> > /* More code */
> >
> > return 0;
> > }
> >
> > return 42;
>
> Now, the WRITE_ONCE() is in the if's arm, and there is clearly a control
> dependency.
Correct.
> Similar cases:
>
> > if(READ_ONCE())
> > foo(); /* WRITE_ONCE() in foo() */
> > return 42;
>
> or
>
> > if(READ_ONCE())
> > goto foo; /* WRITE_ONCE() after foo */
> > return 42;
>
> In both cases, the WRITE_ONCE() again isn't in the if's arm syntactically
> speaking, but again, with rewriting, you can end up with a control
> dependency; in the first case via inlining, in the second case by simply
> copying the code after the "foo" marker.
Again, correct. The LKMM isn't always consistent, and it behaves this
way to try to avoid presuming too much about the optimizations that
compilers may apply.
Alan
