Hi Ali,
I did try this change. I am working on the SPEC CPU2006 benchmark
401.bzip2 and it seems that something is really wrong. I can now see
that there is at least one branch which is detected as mispredicted and
the correct target is set to an instruction which makes no sense at all,
it is neither the target that I would expect if it was taken nor the one
if it wasn't taken. So I guess this change is not the solution.
But do you believe that what I described in my previous email is the
expected behavior or is it more like a bug?
Nikos
On 07/02/2012 10:25 PM, Ali Saidi wrote:
> Hi Nikos,
>
>
>
> I'd be worried that you could have a case where the NPC was never
> checked and the cpu would mispredict a branch but never understand that
> it had. If you do it does it work? I'd expect that you might not
> actually branch at the second beq.
>
>
>
> Thanks,
>
> Ali
>
>
>
>
>
> On 02.07.2012 15:56, Nikos Nikoleris wrote:
>
>> Hi all,
>>
>> I think, I have run into a similar issue.
>>
>> There are cases where a control instruction will take the execution to
>> another control instruction. If both of them are taken and the branch
>> predictor predicts correctly only for the first one it will:
>> * correctly set the predTaken flag and
>> * correctly set the pc field of the PCState structure however the npc
>> might be incorrect.
>> Now this is obviously a misprediction for the second control instruction
>> but not necessarily for the first one as well. The execution could
>> continue without squashing both.
>>
>> Consider the execution of the following simple example in ALPHA.
>> ...
>> 12001847c: beq s2,1200184ac
>> ...
>> 1200184ac: beq s1,1200184d8
>> ...
>>
>> If both of them are taken then the target PCState of the first branch
>> should be set to
>> targetPC = { .pc = 1200184ac, .npc = 1200184d8 }.
>>
>> But the predictor might set it to:
>> targetPC = { .pc = 1200184ac, npc = 1200184b0 }
>>
>> thus it correctly predicts the next instruction after the first branch
>> but misses the right target for the second branch.
>>
>> Are there any unwanted side-effects if we apply the fix that Nathanaël
>> proposed to change the way gem5 detects mispredictions? Or is there
>> something I am missing here?
>>
>> On 27.06.2012 10:56, Nathanaël Prémillieu wrote:
>>> src/cpu/base_dyn_inst.hh:505 - return !(tempPC == predPC); + return
>>> !(tempPC.instAddr() == predPC.instAddr());
>> Thanks,
>>
>> Nikos
>> _______________________________________________
>> gem5-users mailing list
>> [email protected] <mailto:[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
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
