Dear all,
I looked at fetch.cc for the O3CPU and in particular looked at the function
which calls the branch predictor.
bool Fetch::lookupAndUpdateNextPC(const DynInstPtr &inst, TheISA::PCState
&nextPC)
Here are the first couple of lines for quick reference:
bool predict_taken;
if (!inst->isControl()) {
inst->staticInst->advancePC(nextPC);
inst->setPredTarg(nextPC);
inst->setPredTaken(false);
return false;
}
ThreadID tid = inst->threadNumber;
predict_taken = branchPred->predict(inst->staticInst, inst->seqNum,
nextPC, tid);
In the above code there is first a check to see whether or not the current
instruction is a control instruction. If it is not, predict taken = false and
the function returns.
Otherwise, if the current instruction is a control instruction, then the branch
predictor is used for the prediction.
Here is my question. How is it valid to assume that we already know whether or
not the instruction is a control instruction before it is put into the branch
predictor? In other words, does this model of branch prediction implied by the
code bypass the issue of ghost branches(predicting that non-branch instruction
addresses correspond to taken branches)?
One thought I did have was that the branch predictor BTB can filter out the
non-conditional instructions since I assume the BTB will ideally not contain
entries which correspond to non-conditional instructions. Thus, in principle,
if a non-conditional instruction is encountered, even if the branch predictor
predicts the direction to be taken, the instruction will not hit in the BTB and
the overall prediction will be not taken. However, this argument breaks down
when the BTB has partial tags and when false BTB hits can occur.
In summary, how can you know whether or not an instruction is a control
instruction at fetch time, before it has even been decoded?
Thanks,
Scott Blankenberg
_______________________________________________
gem5-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s