Hi Nathanael,
The issue with the change below is that the address could be correct, however the flag bits (e.g. thumb state) or the correct IT state could be wrong. Would it be possible for you to dig a little deeper and see what part of the the PCState objects are causing the mispredicts to happen? Maybe there is something wrong about how we're generating the object in thumb mode, for example, which is resulting in the thumb bit not being set on the predicted PC. Thanks, Ali On 27.06.2012 10:56, Nathanaël Prémillieu wrote: > Hi all, > > I have found some bug related to the RAS in the branch predictor. It > happens that some returns are predicted with the correct PC but not with > the correct PCState structure. Then when the mispredicted status is > checked (in src/cpu/base_dyn_inst.hh:505), these instructions are > detected as mispredicted because the PCState structure are not equal > (the _pc is the same but not the _npc). > > I think this is due to how the target PC is computed by the RAS. > > In my code, I have fixed this doing a comparison on the value of the PC > instead of a comparison of the PCState structures: > > src/cpu/base_dyn_inst.hh:505 > - return !(tempPC == predPC); > + return !(tempPC.instAddr() == predPC.instAddr()); > > However, I am not sure that this the best way to correct this bug. > > Nathanaël Prémillieu > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
