> On March 30, 2015, 10:41 p.m., Steve Reinhardt wrote: > > How about adding something like > > static const FlagsType ORDERED_UNCACHABLE = UNCACHEABLE | STRICT_ORDER; > > > > then using that in place of all the "Request::UNCACHEABLE | > > Request::STRICT_ORDER" expressions? > > Andreas Hansson wrote: > Ironically that is how this patch started out, but we decided against > this compound flag as 1) it makes things less explicit, and 2) if we really > want to introduce compound request flags that should probably be a patch on > its own. There are not that many places where we really want uncacheable and > strictly ordered in the end.
Well, judging by this patch, we always want uncacheable and strictly ordered at the same time... but I can see how that could be just because we're maintaining backwards compatibility here. It still seems like a good idea to me, but it was just a suggestion; if you think it's not worthwhile, I won't push for it. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2720/#review5994 ----------------------------------------------------------- On March 30, 2015, 2:17 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2720/ > ----------------------------------------------------------- > > (Updated March 30, 2015, 2:17 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10786:6c0a6bbc8611 > --------------------------- > mem, cpu: Add a separate flag for strictly ordered memory > > The Request::UNCACHEABLE flag currently has two different > functions. The first, and obvious, function is to prevent the memory > system from caching data in the request. The second function is to > prevent reordering and speculation in CPU models. > > This changeset gives the order/speculation requirement a separate flag > (Request::STRICT_ORDER). This flag prevents CPU models from doing the > following optimizations: > > * Speculation: CPU models are not allowed to issue speculative > loads. > > * Write combining: CPU models and caches are not allowed to merge > writes to the same cache line. > > Note: The memory system may still reorder accesses unless the > UNCACHEABLE flag is set. It is therefore expected that the > STRICT_ORDER flag is combined with the UNCACHEABLE flag to prevent > this behavior. > > > Diffs > ----- > > src/cpu/o3/lsq_unit_impl.hh 8a7285d6197e > src/cpu/translation.hh 8a7285d6197e > src/mem/request.hh 8a7285d6197e > src/cpu/o3/lsq_unit.hh 8a7285d6197e > src/arch/alpha/tlb.cc 8a7285d6197e > src/arch/arm/tlb.cc 8a7285d6197e > src/arch/mips/tlb.cc 8a7285d6197e > src/arch/power/tlb.cc 8a7285d6197e > src/arch/sparc/tlb.cc 8a7285d6197e > src/arch/x86/tlb.cc 8a7285d6197e > src/cpu/base_dyn_inst.hh 8a7285d6197e > src/cpu/minor/lsq.cc 8a7285d6197e > src/cpu/o3/comm.hh 8a7285d6197e > src/cpu/o3/commit_impl.hh 8a7285d6197e > src/cpu/o3/iew_impl.hh 8a7285d6197e > > Diff: http://reviews.gem5.org/r/2720/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
