Hi Scott,
As you correctly point out, the O3 model is being optimistic in its
assumptions. It is even more optimistic in the sense that instruction
fetch deals in micro-ops and not in architectural instructions (although
most often one arch instruction will yield one micro-op).
Therefore, there will be no "quirky" behavior where a non-branch
instruction is predicted taken in gem5. To model the frontend more
accurately, I believe DynInst creation should be delayed until decode,
and fetch should operate based on addresses purely (possibly, this
assumes a specific uarch or a specific ISA). Ideally, the frontend
should be overhauled to implement a more modern decoupled scheme, but
this is an even greater undertaking.
Arthur
On 9/24/21 3:02 AM, Scott Blankenberg via gem5-users wrote:
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 -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
