For 2 and 3 below, what are the other stats changes? I'd expect some small difference due to introduction of a slightly new feature in the inorder model and I think it'd be OK to commit in those sparc cases. I'm more worried if you are breaking for alpha or mips since those are more tested in the inorder model.
For 1), like Andreas has said, I've had situations where I've had to go debug on zizzer and it turns out that the issue is some unitialized variable that only manifests itself when run on zizzer. Since it's a branch predictor chagne, I'd theorize it's also probably safe to commit given the suspicions of myself + Andreas on that workload. With that said, are there any other obstacles to committing this change? I push the issue because I dont get as much spare time to go and debug gem5 like I use to, so I'm hoping the effort I put into finding that small difference in the inorder branch predictor makes it into an actual changeset. > > Seems like I will not be able to keep my promise. Following differences > were found after running all the regression tests -- > > 1. tests/long/se/20.parser/ref/arm/linux/o3-timing/ > sim_insts 505237723 505237723 0 +0.00% > sim_ops 569624283 569624283 0 +0.00% > sim_ticks 199845137000 199893963500 48826500 > +0.02% > > 2. tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/ > None to sim_insts, sim_ops, sim_ticks, but other stats change. > > 3. tests/quick/se/02.insttest/ref/sparc/linux/inorder-timing/ > None to sim_insts, sim_ops, sim_ticks, but other stats change. > > Ali, is this fine with you? > > > -- > Nilay > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
