> 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. > > > > Steve Reinhardt wrote: > 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.
Spoke too soon... it turns out that the O3 model relies on the physical zero register having the same index as the logical zero register <shudder>. This happens to be the case when you push all the physical registers (starting at index zero) on a queue, then pull them off the head when you do the initial assignment to logical registers (also starting at index zero). When you replace the queue with a stack, you break this happy coincidence, and it stops working. So I'll leave it as a queue for now... with some effort, we could convert it to a stack, but I think that's best left for a separate patch. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1987/#review4627 ----------------------------------------------------------- On Aug. 27, 2013, 5:12 p.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1987/ > ----------------------------------------------------------- > > (Updated Aug. 27, 2013, 5:12 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9852:d1f17f13ef26 > --------------------------- > 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 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/cpu.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/cpu.cc 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/cpu_policy.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/free_list.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/free_list.cc 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/regfile.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/regfile.cc PRE-CREATION > src/cpu/o3/rename_impl.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/rename_map.hh 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > src/cpu/o3/rename_map.cc 3f6e2f267aba6571c478fcd83c4a1b9d6564084f > > 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
