> On March 31, 2015, 5:41 a.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?
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. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2720/#review5994 ----------------------------------------------------------- On March 30, 2015, 9: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, 9: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
