Re: Does Itanium permit speculative stores?

[Peter Zijlstra]

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.

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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/