Hi Everyone,
As Amin pointed out earlier, it seems like I've managed to commit some buggy branch predictor draining. Most of the O3 CPU components have methods (drainSanityCheck()) that allow them to do potentially expensive (i.e., tests that we don't want to do in isDrained() on every cycle when draining) when the CPU has determined that it has drained properly.
The branch predictor currently assume that the branch predictor tables are empty when the system is drained. This might be a left over from an early revision of the patch where I flushed the branch predictor to get make debugging of CPU swiching/checkpointing easier.
There are two possible solutions to the current draining bug, each with slightly different trade-offs:
1. We flush the branchpredictor tables on a drain. This makes it slightly easier to compare traces from a system that executes a drain & resume pair to a system that checkpoints (or switches between two O3 CPUs) and resumes. However, this might lead to somewhat surprising results if you do frequent checkpointing.
2. We simple live with potentially stale data in the branch predictors and just remove the broken sanity check.
I'm in favour of the first solution as it makes debugging easier. I don't think it'll cause any big problems since draining should be fairly infrequent.
//Andreas _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
