> On Aug. 24, 2013, 2:01 p.m., Ali Saidi wrote: > > src/cpu/o3/free_list.hh, line 58 > > <http://reviews.gem5.org/r/1987/diff/1/?file=37242#file37242line58> > > > > queue is certainly nice for readability here, but i'm wondering (and > > not saynig to go do this), but if a vector would actually be faster if you > > treated it like a stack. It's just a bit funny that we typedef the size so > > we can have a 16 byte index and two 64 byte pointers. > >
I switched it to std::stack<PhysRegIndex> and that seems to work. The docs I found says that defaults to using a deque as the underlying container. It's a one-line change to go to std::stack<PhysRegIndex, std::vector<PhysRegIndex> > if you think that's preferable. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1987/#review4627 ----------------------------------------------------------- On Aug. 21, 2013, 5:40 p.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1987/ > ----------------------------------------------------------- > > (Updated Aug. 21, 2013, 5:40 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9850:65d5069b045e > --------------------------- > cpu/o3: clean up rename map and free list > > Restructured rename map and free list to clean up some > extraneous code and separate out common code that can > be reused across different register classes (int and fp > at this point). Both components now consist of a set > of Simple* objects that are stand-alone rename map & > free list for each class, plus a Unified* object that > presents a unified interface across all register > classes and then redirects accesses to the appropriate > Simple* object as needed. > > Moved free list initialization to PhysRegFile to better > isolate knowledge of physical register index mappings > to that class (and remove the need to pass a number > of parameters to the free list constructor). > > Causes a small change to these stats: > cpu.rename.int_rename_lookups > cpu.rename.fp_rename_lookups > because they are now categorized on a per-operand basis > rather than a per-instruction basis. > That is, an instruction with mixed fp/int/misc operand > types will have each operand categorized independently, > where previously the lookup was categorized based on > the instruction type. > > > Diffs > ----- > > src/cpu/o3/SConscript 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu_policy.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/free_list.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/free_list.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/regfile.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/regfile.cc PRE-CREATION > src/cpu/o3/rename_impl.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/rename_map.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/rename_map.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > > Diff: http://reviews.gem5.org/r/1987/diff/ > > > Testing > ------- > > > Thanks, > > Steve Reinhardt > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
