----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/520/#review915 -----------------------------------------------------------
Should we put an assert in there to make sure no access is bigger than 16 bytes? Also what about unaligned accesses? I think those will be split on cache block boundaries which may be bigger or smaller than 16 bytes. We might have an access that spans from one 16 byte chunk to the next. These aren't really problems with this change, but it might make them easier to hit. I'm assuming this had some effect on the regressions. Did things generally go faster, slower, etc.? - Gabe On 2011-02-27 18:52:51, Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/520/ > ----------------------------------------------------------- > > (Updated 2011-02-27 18:52:51) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > O3: Tighten memory order violation checking to 16 bytes. > > The comment in the code suggests that the checking granularity should be 16 > bytes, however in reality the shift by 8 is 256 bytes which seems much > larger than required. > > > Diffs > ----- > > src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 > > Diff: http://reviews.m5sim.org/r/520/diff > > > Testing > ------- > > > Thanks, > > Ali > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
