Hi,
I suspect one of a few things might be behind what you think you are seeing.
1) "I have observed that call and return instructions are predicted as if these
instructions were conditional branches."
The ARMv7 ISA actually does have conditional calls and returns (this is a
consequence of letting almost any instruction be predicated). The
disassembly generated by gem5 often lacks these additional conditional
specifiers, even though the instructions are executed properly.
If this is some other ISA (like x86), I'd verify the
"IsCondCtrl/IsUncondCtrl" flags on the given instruction are properly set.
This could be an ISA-specific error. This code in the predictor is
supposed to guard against that case, but its up to the ISA implementer to
do things right.
if (inst->isUncondCtrl()) {
DPRINTF(Branch, "[tid:%i]: Unconditional control.\n", tid);
pred_taken = true;
// Tell the BP there was an unconditional branch.
uncondBranch(bp_history);
} else {
++condPredicted;
pred_taken = lookup(pc.instAddr(), bp_history);
DPRINTF(Branch, "[tid:%i]: [sn:%i] Branch predictor"
" predicted %i for PC %s\n", tid, seqNum, pred_taken, pc);
}
2) "Moeover, when a call instruction is predited taken and no target
address is found in BTB the prediction is changed to not-taken and RAS
entry associated with this call is removed. :"
The RAS maintenance is a "fun" bit of code in the predictor. There have
been bugs discovered/fixed in it recently. Seems the fix is just to push
the proper new RAS in the squash function for the call. This has probably
made it so long because it is unlikely to be exercised often (since the
calls will normally hit in the BTB).
On Thu, Nov 13, 2014 at 4:51 AM, Adrián Colaso Diego via gem5-users <
[email protected]> wrote:
> Hi all,
>
> I have observed that call and return instructions are predicted as if
> these instructions were conditional branches. Such predictions even
> modify branch history register.
> As a consequence many times these instructions are predicted not-taken
> and squash function must be called after they are executed.
>
> Moreover, when a call instruction is predited taken and no target
> address is found in BTB the prediction is changed to not-taken and RAS
> entry associated with this call is removed. Squash function is called
> after call instruction is executed to update BTB but RAS is not updated
> so return instruction will get a wrong address.
>
> Am i missing something?
>
> Thanks,
> Adrian
>
>
>
>
> _______________________________________________
> 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
