By: EBFE (x.delete@this.y.com), February 19, 2013 1:03 am
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 17, 2013 5:28 pm wrote:
> I find multiple condition registers attractive partially because such can be less expensive front-end
> registers (future file for an OoO implementation) allowing early branch resolution. In theory,
> branches whose conditions are set early could be resolved just after branch prediction (the predictor
> could indicate that the branch is a candidate for early resolution and what condition register+condition
> is tested), but even just after decode branch resolution could have some benefits.
>
> Admittedly, the scope for potential improvement (conditions that can be set early) is very limited
> and lack of compiler support is probably a significant issue (in some cases, early setting would
> require interprocedural optimization). The scope is perhaps slightly larger than one might expect,
> however, since after a branch misprediction the current at time of mispredicted branch values are
> likely to be in the front end by decode time for the redirected instruction stream.
>
By "early branch resolution" you mean that the branch simply doesn't predict and stall for the condition?
And its candidate usecase is limited to high-misprediction (or use prediction), not-in-loop-body (or use CFD) branches.
And compiler has to shuffle code to fill a potentially large and unpredictable bubble, which IMO is unlikely to find that much work to fill.
> I find multiple condition registers attractive partially because such can be less expensive front-end
> registers (future file for an OoO implementation) allowing early branch resolution. In theory,
> branches whose conditions are set early could be resolved just after branch prediction (the predictor
> could indicate that the branch is a candidate for early resolution and what condition register+condition
> is tested), but even just after decode branch resolution could have some benefits.
>
> Admittedly, the scope for potential improvement (conditions that can be set early) is very limited
> and lack of compiler support is probably a significant issue (in some cases, early setting would
> require interprocedural optimization). The scope is perhaps slightly larger than one might expect,
> however, since after a branch misprediction the current at time of mispredicted branch values are
> likely to be in the front end by decode time for the redirected instruction stream.
>
By "early branch resolution" you mean that the branch simply doesn't predict and stall for the condition?
And its candidate usecase is limited to high-misprediction (or use prediction), not-in-loop-body (or use CFD) branches.
And compiler has to shuffle code to fill a potentially large and unpredictable bubble, which IMO is unlikely to find that much work to fill.