David Kanter (dkanter.delete@this.realworldtech.com) on August 15, 2012 1:14 am wrote:
> 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

Strictly speaking, stores have no latency (except you consider latency of store-to load forwarding as a store lentancy) *beacuse* the could be buffered.

> 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.

But, assuming you really want to avoid branch, because you know that you can't predict it, the replacement technique (select between real and dummy store addresses) is no better, power wise, then conditional store itself. If anything, probably worse.
Still, avoiding complication of store path logic by predication is probably A Good Thing regardless of power cost.

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

Conditional stores are potentially very useful for quicksort family of algorithms. One could argue that in todays computing environments quicksort is no more a sorting engine choice since mergesort tends to be faster and with today's abundance of main memory in-place properties of quicksort are less beneficiary. However quicksort core loop is not just about sorts. For example, I am not aware of better algorithm for nth_element.

> > 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