On Tue, Nov 12, 2013 at 07:26:17PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 12, 2013 at 06:00:26PM +0000, Luck, Tony wrote:
> > > Does Itanium permit speculative stores? For example, on Itanium what are
> > > the permitted outcomes of the following litmus test, where both x and y
> > > are initially zero?
> >
> > We have a complier visible speculative read via the "ld.s" and "chk"
> > instructions. But
> > there is no speculative write ("st.s") instruction. I think you are asking
> > "can out of order
> > writes become visible in this scenario?"
> >
> > CPU 0 CPU 1
> >
> > r1 = ACCESS_ONCE(x); r2 = ACCESS_ONCE(y);
> > if (r1) if (r2)
> > ACCESS_ONCE(y) = 1; ACCESS_ONCE(x) = 1;
> >
> > > In particular, is the outcome (r1 == 1 && r2 == 1) possible on Itanium
> > > given this litmus test?
> >
> > The "ACCESS_ONCE" macro casts to volatile - which will make gcc generate
> > ordered "ld.acq" and "st.rel" instructions for your code snippets. So I
> > think
> > you should be fine.
>
> Cute that volatile generates barrier instructions.
>
> But no; I think Paul accidentally formulated his question in C (since we
> all speak C) but meant to ask an architectural question.
I got both answers, so I am good. ;-)
> So the point we're having a discussion on is if any architecture has
> visible speculative STORES and if there's an architecture that doesn't
> have control dependencies.
>
> On the visible speculative STORES; can, if in the above example we have
> regular loads/stores:
>
> LOAD r1, x LOAD r2, y
> IF (r1) IF (r2)
> STORE y, 1 STORE x, 1
>
> we observe: r1==1 && r2==1
>
> In order for that to be true; we must be able to observe the stores
> before the loads are complete -- and therefore before the branches are a
> certainty.
>
> Typically if an architecture speculates on branches the result doesn't
> become visible/committed until the branch is a certainty -- ie. linear
> branch history.
>
> Alternatively:
>
> x:=0
>
> IF (cond) LOAD r1,x
> STORE x,1
> STORE x,2
>
> Can r1 ever be 1 if we know 'cond' will never be true (runtime
> constraint, not compile time so the branch cannot be omitted).
I would have been OK mandating use of ACCESS_ONCE() to prevent speculative
stores, but it is even nicer that it is not necessary.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
