lkml.org 
[lkml]   [2021]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency
On Thu, Oct 14, 2021 at 08:19:54PM +0200, Florian Weimer wrote:
> * Paul E. McKenney:
>
> >> > 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).
>
> > (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

\
 
 \ /
  Last update: 2021-10-14 23:10    [W:0.112 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site