[gem5-users] O3CPU Branch Predictor Similation

[Scott Blankenberg via gem5-users]

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