ideal model and value predictor support #297
Conversation
Referenced the implementation of the exit callback. Change-Id: I040b7dcbcf9bf5e9c7fcae4fa062b55df7de3753
* add support for int add-type instructions. * Added flag support for certain nonspec and system instructions to align gem5 behavior with the ideal model. Change-Id: Ifef310b5b662eb0e1517e59964fdc0cc13caa3f5
Change-Id: Ie7d744bcf13751a797c00397357d8b1b326f1e93
Change-Id: I67e94d719a39ef202621c6d5755a5335ecda4096
Change-Id: If315236b42cbd515eac3a1fcedebc08d66756fe6
Change-Id: Ibd23e2c7c129396a393a9ff51ae05c1e11fa00d6
* Added interfaces for the value predictor and ideal model in O3, ensuring that the original O3 execution remains unaffected when they are disabled. * The code for the value predictor will be further refined in future updates. Change-Id: I0a92c99ab0f5d8906911c942a75e241a0e070a87
Change-Id: Icdf2c27d2d2a9b8f908f8b587c9de6c0b87f5960
| buildPredMetaData(ValuePredType::EStride)); | ||
| vpPredMetaData->pc = instruction->getPC(); | ||
| vpPredMetaData->seq_no = instruction->seqNum; | ||
| instruction->vpResult = valuePredictor->valuePredict(vpPredMetaData); |
There was a problem hiding this comment.
Should it do predict at rename?
Allocate new physical register and remap to the predicted value.
There was a problem hiding this comment.
Should it do predict at rename? Allocate new physical register and remap to the predicted value.
In fact, the predicted values are indeed used in the Rename stage. What is being simulated here is a scenario where value prediction occurs when the instruction is fetched in the Fetch stage, and the predicted value is utilized in the Rename stage—essentially frontend prediction with backend consumption.
From a microarchitectural implementation perspective, accessing the value predictor in the Fetch stage instead of the Rename stage allows the predictor to obtain incoming instructions earlier. This leverages the latency between the frontend and backend to hide the overhead of value prediction.
| @@ -1270,6 +1276,52 @@ Rename::renameDestRegs(const DynInstPtr &inst, ThreadID tid) | |||
| rename_result.second); | |||
|
|
|||
| ++stats.renamedOperands; | |||
|
|
|||
| if ((cpu->idealModelEnabled() && cpu->idealModelConfig->isValuePredSupported()) || | |||
There was a problem hiding this comment.
This block seems can be optimized.
There was a problem hiding this comment.
This block seems can be optimized.
Currently, there are two scenarios where value prediction is performed:
- When the ideal model is enabled
- When the value predictor is used independently
The if condition here is used to distinguish between these two cases. The implementation of the ideal model is incompatible with the actual value predictor, which is why this "if" is necessary.
Furthermore, the strict checks on which instructions and registers are eligible for value prediction are currently unavoidable. This is because the current implementation only supports value prediction for arithmetic instructions and standard loads, necessitating these strict checks on instructions and registers.
Change-Id: I8ac183aa0d4b981fd3d2f8dba52630e57d30474f
Change-Id: I845474e03f749e5d1f71ae5f69cb60453924b881
|
Due to the lack of consideration for the details in the instruction fetch stage, the ideal model still has some bugs that are currently being fixed. |
Change-Id: Id10c087f1c5741e1da4258c11ae274281960eb41
related: #215 #188 OpenXiangShan/NEMU#806
Added support for the ideal model and value prediction in this PR.
Through my testing on the server, both of these additions do not affect the execution of xs-gem5 when disabled.
The upstream merge of nemu will be a slow process, as the upstream nemu differs significantly from the version currently used for difftest, requiring time for integration. If this submission is accepted, I will first provide a precompiled version in the ready-to-run repository.