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:

with

is

how the target PC is computed by the RAS.

this doing a comparison on the value of the PC

comparison of the PCState structures:

src/cpu/base_dyn_inst.hh:505

!(tempPC.instAddr() == predPC.instAddr());

that this the best way to correct this bug.

list

http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

From what I have understand on the example I have worked on to detect
the bug, the predicted address is computed depending on the flag of the
Call for the thumb bit. But when the check is done, the tempPC is
computed depending on flag of the Return. Thus, if the Call and the
Return are not in the same mode, the _npc of PredPC and tempPC are not
the same.
In my example, tempPC._npc = tempPC._pc + 2 (tumb mode) and Pred._npc =
Pred._pc + 4

Nathanaël

Le 27/06/2012 17:18, Ali Saidi a écrit :

Hi Nathanaël,

So are you saying that everything is predicted
correctly, however the check is truly wrong in this case?

Thanks,

Ali

On 27.06.2012 12:03, Nathanaël Prémillieu wrote:

the bug, the predicted address is computed depending on the flag of the

computed depending on flag of the Return. Thus, if the Call and the

Return are not in the same mode, the _npc of PredPC and tempPC are not

and Pred._npc =

Yes, the PC (the _pc in the PCState structure) are the same, but the
check checks also if the NPC (the _npc int the PCState structure) are
the same. And here this is not the case, hence the test detects it as
mispredicted.

Nathanaël

Le 27/06/2012 19:30, Ali Saidi a écrit :

Hrm... Anyone have an idea how to fix this?

Ali

On 27.06.2012
14:27, Nathanaël Prémillieu wrote:

PCState structure) are the same, but the

(the _npc int the PCState structure) are

not the case, hence the test detects it as

Nathanaël

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:

Thanks,

Nikos

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:

have run into a similar issue.

instruction will take the execution to

both of them are taken and the branch

only for the first one it will:

and

npc

the second control instruction

as well. The execution could

Consider the execution of the following simple example in ALPHA.

12001847c: beq s2,1200184ac

branch

1200184d8 }.

= 1200184ac, npc = 1200184b0 }

instruction after the first branch

second branch.

fix that Nathanaël

mispredictions? Or is there

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());

list

http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

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: