Hi Nathanaël, It's quite possible there is a bug. Unfortunately, I don't think anyone knows the branch predictor code extremely well.
Please see inline. On May 21, 2012, at 3:36 PM, Nathanaël Prémillieu wrote: > Hi all, > > I'am currently looking at the branch prediction code. > > In the predict function (src/cpu/o3/bpred_unit_impl.hh: 160), if the BTB > entry is not valid for a taken prediction, the prediction pred_taken is > changed to false and the history is changed. Moreover, the RAS is popped if > it is a call (l.254). But the RAS is popped only if the call is conditional > (I don't know exactly why). > If it is an unconditional call, the RAS is not popped. I think the reason that the code is like this is that you're definitely branching in this case. If you don't Because in this case you're definitely branching. In the case of not having a target fetch will be re-directed to the target when the branch resolves, so there will never be another opportunity to put the branch into the return address stack. However, I would assume that the conditional branch would have the same issue, so this seems to be a problem. > And if this unconditional call need to be squashed (by the squash function > l.298), the RAS needs to be popped. For this instruction, the validBTB flag > is not set, so the line 316 of the squash function is not executed ans thus, > the entry is not popped. That seems to be an issue too. > > From my current understanding of the code, this seems to be a bug. As I don't > know the whole code, this case can be taken care of in some other function or > it is not a problem. > > Any idea on the subject ? I think it might be a problem. Could you try to suggest a fix and see if it effects performance? Thanks, Ali _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
