Hi Erik,
I posted a patch last night that fixed some issues with the local predictor, but it all certainly could be cleaned up. We'd be very happy to commit patches that clean up and parameters and code to address the issues you've identified. Thanks, Ali On 25.10.2012 11:31, Erik Tomusk wrote: > Hi All, > > It seems to me that some of the tournament branch predictor parameters > are redundant, at least given how the predictor is currently > implemented. Has anyone else run into this? > > Specifically, the tournament predictor takes nine parameters that can be > configured independently: > localPredictorSize, > localCtrBits, > localHistoryTableSize, > localHistoryBits, > globalPredictorSize, > globalHistoryBits, > globalCtrBits, > choicePredictorSize, > choiceCtrBits > > However, the code assumes that 2^(globalHistoryBits) = > globalPredictorSize = choicePredictorSize, and 2^(localHistoryBits) = > localPredictorSize. These assumptions aren't tested, so it's possible to > crash gem5 if, for example, 2^(globalHistoryBits) > globalPredictorSize. > > There's also a redundancy in the three *CtrBits. The prediction > threshold is based on localCtrBits, but used for the other two as well. > The *CtrBits can be defined independently, but it looks like the > saturating counters' thresholds will be skewed unless all the *CtrBits > are the same. (There is a comment that the thresholds should be separated) > > So the question is, how much of this is bug, and how much is feature? > Has this caused problems for anyone? > > Thanks, > Erik
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
