The change may have made the branch predictor code behave incorrectly, for instance an instruction could execute twice, a misspeculated instruction could sneak through and commit, an instruction could be skipped, a branch could be "corrected" to go down the wrong path. There are lots of things that could go wrong. Alternatively, the branch predictor might have just gotten better and put more stress on some other part of the CPU, or coincidentally lined up circumstances which expose another bug. You should try to find where execution diverges between O3 and the atomic CPU, possibly using tracediff or possibly using the checker CPU. I'm not sure the checker works correctly with x86, but if it does this is pretty much exactly what it's for.
Gabe On 05/14/12 17:22, mingkai huang wrote: > Hi, > I tried to use gem5 to run SPEC2006 in x86 O3 mode. When I ran bzip2, > it failed with: > fatal: Over max stack size for one thread > My command line is: > build/X86/gem5.fast configs/example/se.py --cpu-type=detailed --caches > -c bzip2 -o "input.program 5" > The version of my gem5 is 8981. > Bzip2 can run correctly in atomic mode. > I binary searched where the problem happened first, and found version > 8842. I noticed this patch is about branch prediction, and I don't > understand why this can affect the correctness of an application. > Before 8842, Bzip2 can run correctly in both mode, but the outputed > numbers of "info: Increasing stack size by one page." are not equal. > Because of email size limitation, I can't attached the file I used. > _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
