cpu-o3: Avoid passing ReExec 'faults' on CPU tracing interface

The O3 model uses ReExec faults to flush the pipeline and restart
after a memory ordering violation, e.g. due to an incoming snoop.

These, just like branch mispredict flushes, are not architectural
faults but micro-architectural events, and should therefore not
show up on the instruction tracing interface.

This adds a check on faulting instructions in commit, to verify
if the instruction faulted due to ReExec, to avoid tracing it.

Change-Id: I1d3eaffb0ff22411e0e16a69ef07961924c88c10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30554
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This commit is contained in:
Michiel W. van Tol
2020-06-04 16:01:26 +01:00
committed by Giacomo Travaglini
parent f8dceef505
commit 70c4b1c608

View File

@@ -1259,7 +1259,11 @@ DefaultCommit<Impl>::commitHead(const DynInstPtr &head_inst, unsigned inst_num)
"[tid:%i] [sn:%llu] Committing instruction with fault\n",
tid, head_inst->seqNum);
if (head_inst->traceData) {
if (DTRACE(ExecFaulting)) {
// We ignore ReExecution "faults" here as they are not real
// (architectural) faults but signal flush/replays.
if (DTRACE(ExecFaulting)
&& dynamic_cast<ReExec*>(inst_fault.get()) == nullptr) {
head_inst->traceData->setFaulting(true);
head_inst->traceData->setFetchSeq(head_inst->seqNum);
head_inst->traceData->setCPSeq(thread[tid]->numOp);