On Wed, 02 Dec 2009 11:27:47 -0000, Gabe Black <[email protected]> wrote:
> Timothy M Jones wrote: >> On Wed, 02 Dec 2009 01:31:03 -0000, Gabriel Michael Black >> <[email protected]> wrote: >> >> >>> Quoting Timothy M Jones <[email protected]>: >>> >>> >>>> Thanks Gabe. >>>> >>>> I've run all regressions and there are some that fail. I've checked >>>> the >>>> differences and it's mainly changes in the number of DTB accesses (as >>>> expected). In some cases there are more Dcache accesses too (also >>>> expected if speculative I guess). In general though, the number of >>>> ticks >>>> stays exactly the same. >>>> >>> Why is that expected? Aren't you replacing one body of code with a >>> functionally identical body that's just organized differently? I can >>> imagine new functionality making certain benchmarks behave >>> differently, but for all the (relatively) stable ISAs, what accesses >>> are done, which ones are split, etc. should be pretty much the same. >>> >>> >> Well, the problem is when you get speculative memory accesses. Even in >> the ISAs that don't need split loads and stores, an address on a >> speculative path can generated that requires splitting. Of course, >> these >> instructions are later squashed, but their DTB and Dcache accesses might >> have already been performed, leading to more accesses than in the >> reference stats. >> >> With Steve's suggestion to limit split accesses to only those ISAs that >> require it, this wouldn't be an issue at all. >> > > That makes sense. That only applies to O3, correct? All the timing > simple CPU regressions pass? Sorry for the 20 questions, but I just want > to be sure everything makes sense. > That's right. It's only O3 regressions that failed. All timing simple and inorder regressions pass without problems. I'm not fussed about being asked lots of questions. It's good for me to make sure I've done everything right too! Cheers Tim -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
