> 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? > > 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. > > Steve Reinhardt wrote: > 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.
All devices stick to UNCACHEABLE only. Also, have a look at http://reviews.gem5.org/r/2721/ - 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
