On Sat, Feb 25, 2023 at 07:09:05PM -0800, Boqun Feng wrote:
On Sat, Feb 25, 2023 at 09:29:51PM -0500, Alan Stern wrote:Good guess; maybe that was the reason. [...]
On Sat, Feb 25, 2023 at 05:01:10PM -0800, Paul E. McKenney wrote:Because plain store can be optimzed as an "store only if not equal"?
A few other oddities:The LKMM doesn't believe that a control or data dependency orders a
litmus/auto/C-LB-Lww+R-OC.litmus
Both versions flag a data race, which I am not seeing. It appears
to me that P1's store to u0 cannot happen unless P0's store
has completed. So what am I missing here?
plain write after a marked read. Hence in this test it thinks that P1's
store to u0 can happen before the load of x1. I don't remember why we
did it this way -- probably we just wanted to minimize the restrictions
on when plain accesses can execute. (I do remember the reason for
making address dependencies induce order; it was so RCU would work.)
As the following sentenses in the explanations.txt:
The need to distinguish between r- and w-bounding raises yet another
issue. When the source code contains a plain store, the compiler is
allowed to put plain loads of the same location into the object code.
For example, given the source code:
x = 1;
the compiler is theoretically allowed to generate object code that
looks like:
if (x != 1)
x = 1;
thereby adding a load (and possibly replacing the store entirely).
For this reason, whenever the LKMM requires a plain store to be
w-pre-bounded or w-post-bounded by a marked access, it also requires
the store to be r-pre-bounded or r-post-bounded, so as to handle cases
where the compiler adds a load.
So perhaps the original reason is not valid now
that the memory model explicitly includes tests for stores being
r-pre/post-bounded.
Alan