Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 14, 2012 7:27 am wrote:
> none (none.delete@this.none.com) on August 14, 2012 6:56 am wrote:
> [snip]
> >
> In theory yes, predication looks great.
>
> Maybe not great, but certainly
> useful.
>
> >In practice, as I said in another post, it might constrain too
> > many other things in your micro-architecture, which actually might reduce
> > achievable performance. I really think spending the budget transistor
> and
> > design specification in doing a smarter branch predictor is
> better.
>
> I do not mean to imply that the ARM architects were ignorant or
> stupid. However, I think providing conditional stores is more attractive than
> forcing software to implement them by conditionally selecting a store address.

I am skeptical. Stores are very complicated, because of the impact on coherency and ordering. They are also rather long latency and tend to get heavily buffered. That's exactly the kind of thing I wouldn't want to predicate. Who knows what odd side-effects might occur?

Predicating a register to register move is tolerable. The scope is very limited, and you aren't going to run into too many issues.

More to the point, stores are damn power hungry. You need to:

1. Probe TLB
2. Write to store buffer (for forwarding)
3. Probe tags
4. Write to cache

That's wasting a huge amount of energy if your predicate is false. Consequently, you'd want to evaluate the predicate before the store address is available, to avoid wasting power.

I also don't see what particular use cases predicated stores will really target. For vectors, they might make sense...but not normal scalars.

> An implementation of predicated stores would only have to be equal to the
> software workaround (and such could probably be implemented much like the
> software version by cracking the store into an address generation µop and
> a data µop where the address generation could produce a null
> address--which would not match with any loads and would commit the store data to
> no-place--No Big Deal [maybe]).

Now you have another dependency feeding into the store. Doesn't make life any easier.

> Wish branches (that inform hardware of a
> hammock that is likely to benefit from predication) might be better (moving such
> into the microarchitecture--which might treat such as an ordinary branch,
> predicate if "sufficiently short", or make a dynamic choice on handling based on
> prediction confidence information--while still allowing software to communicate
> information that could avoid expensive mispredictions), but predicated stores
> (in my ignorance) do not seem especially limiting.

They don't seem like a good idea.

DK