Re: branch prediction, renaming, joins

Stefan Monnier wrote:

> Current approaches to branch prediction suffer from the fact that they do
> not take into account control flow joins, so if a branch is mispredicted
> the processor will throw away all the subsequent speculatively executed
> stuff, even though some part of it might not necessarily depend on the
> branch itself.
>
> More concretely, if you have:
>
>    if (a)
>       b;
>    else
>       c;
>    d;
>
> and you mispredict the outcome of `a', you don't necessarily have to throw
> away the speculative execution of `d'.
>
> The only approach I know of that tries to solve this problem does it by
> circumventing it: remove the branch and use predicated execution instead.
>
> Are there other approaches to solving this issue ?
> I guess multiscalar stuff is related (thought typically at a coarser
> granularity, but that's still relevant).

In your particular example, (d) must be independent of the outcome of 
the if block, which means that a decent compiler would probably hoist it 
up above instead, right?

What I'm saying is that as long as (d) depend upon (b) and/or (c), 
there's no way it _can_ be stitched back together, at least not until it 
is clear that no aliasing occured.

Terje
--
- <[EMAIL PROTECTED]>
"almost all programming can be viewed as an exercise in caching"