On Thu, Oct 14, 2021 at 08:19:54PM +0200, Florian Weimer wrote:

* Paul E. McKenney:

quoted

quoted

quoted

Yes, I know, we for sure have conflicting constraints on "reasonable"
on copy on this email.  What else is new?  ;-)

I could imagine a tag of some sort on the load and store, linking the
operations that needed to be ordered.  You would also want that same
tag on any conditional operators along the way?  Or would the presence
of the tags on the load and store suffice?

If the load is assigned to a local variable whose address is not taken
and which is only assigned this once, it could be used to label the
store.  Then the compiler checks if all paths from the load to the
store feature a condition that depends on the local variable (where
qualifying conditions probably depend on the architecture).  If it
can't prove that is the case, it emits a fake no-op condition that
triggers the hardware barrier.  This formulation has the advantage
that it does not add side effects to operators like <.  It even
generalizes to different barrier-implying instructions besides
conditional branches.

So something like this?

	tagvar = READ_ONCE(a);
	if (tagvar)
		WRITE_ONCE_COND(b, 1, tagvar);

Yes, something like that.  The syntax only makes sense if tagvar is
assigned only once (statically).

quoted

(This seems to me to be an eminently reasonable syntax.)

Or did I miss a turn in there somewhere?

The important bit is that the compiler emits the extra condition when
necessary, and the information in the snippet above seems to provide
enough information to optimize it away in principle, when it's safe.
This assumes that we can actually come up with a concrete model what
triggers the hardware barrier, of course.  For example, if tagvar is
spilled to the stack, is it still possible to apply an effective
condition to it after it is loaded from the stack?  If not, then the
compiler would have to put in a barrier before spilling tagvar if it
is used in any WRITE_ONCE_COND statement.

In all the weakly ordered architectures I am aware of, spilling to
the stack and reloading preserves the ordering.  The ordering from
the initial load to the spill is an assembly-language data dependency,
the ordering from the spill to the reload is single-variable SC, and
the ordering beyond that is the original control dependency.

						Thanx, Paul