Discussion:
[gem5-dev] Review Request 1987: cpu/o3: clean up rename map and free list
(too old to reply)
Steve Reinhardt
2013-08-22 00:40:54 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------

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
Ali Saidi
2013-08-24 21:01:07 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/#review4627
-----------------------------------------------------------



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4379>

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.




src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4377>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4378>

cost


- Ali Saidi
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------
(Updated Aug. 22, 2013, 12:40 a.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).
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
Ali Saidi
2013-08-24 21:01:54 UTC
Permalink
otherwise ship it.


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/#review4627
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------
(Updated Aug. 22, 2013, 12:40 a.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).
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
Steve Reinhardt
2013-08-28 00:08:37 UTC
Permalink
Post by Steve Reinhardt
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
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
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).
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
Steve Reinhardt
2013-08-28 03:55:44 UTC
Permalink
Post by Steve Reinhardt
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.
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
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
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).
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
Andreas Hansson
2013-08-25 12:28:19 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/#review4630
-----------------------------------------------------------



src/cpu/o3/cpu.cc
<http://reviews.gem5.org/r/1987/#comment4380>

Spacing around -, also extraneous parentheses around RegIndex



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4381>

bool?



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4382>

Somehow the parameters do not seem matched with the signature here.



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4383>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4384>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4385>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4386>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4387>

const



src/cpu/o3/free_list.hh
<http://reviews.gem5.org/r/1987/#comment4388>

const



src/cpu/o3/free_list.cc
<http://reviews.gem5.org/r/1987/#comment4389>

Should not the cpu bit be the parent name, and should it not also contain the system bit etc?



src/cpu/o3/regfile.cc
<http://reviews.gem5.org/r/1987/#comment4390>

I assume there is a good reason to not make these std::vectors.



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4391>

freeList(NULL)?



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4392>

const



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4393>

const?



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4394>

const



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4395>

const



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4396>

const



src/cpu/o3/rename_map.hh
<http://reviews.gem5.org/r/1987/#comment4397>

const

unsigned here and for numFreeEntries in the maps?



src/cpu/o3/rename_map.cc
<http://reviews.gem5.org/r/1987/#comment4398>

Assert(freeList == NULL && map.empty());


Some minor bits and pieces

- Andreas Hansson
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------
(Updated Aug. 22, 2013, 12:40 a.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).
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
Steve Reinhardt
2013-08-28 00:09:17 UTC
Permalink
Post by Steve Reinhardt
src/cpu/o3/free_list.hh, line 137
<http://reviews.gem5.org/r/1987/diff/1/?file=37242#file37242line137>
Somehow the parameters do not seem matched with the signature here.
I'm not sure what you mean... looks OK to me. I think the diff is misleading, as I took what was one class and split it into two.
Post by Steve Reinhardt
src/cpu/o3/regfile.cc, line 43
<http://reviews.gem5.org/r/1987/diff/1/?file=37245#file37245line43>
I assume there is a good reason to not make these std::vectors.
No good reason... making them vectors does clean up initialization & destruction a bit.
Post by Steve Reinhardt
src/cpu/o3/free_list.hh, line 147
<http://reviews.gem5.org/r/1987/diff/1/?file=37242#file37242line147>
const
Actually this is not const, it's allocating a free reg from the list (and removing it).
Post by Steve Reinhardt
src/cpu/o3/free_list.hh, line 150
<http://reviews.gem5.org/r/1987/diff/1/?file=37242#file37242line150>
const
same here
Post by Steve Reinhardt
src/cpu/o3/cpu.cc, line 349
<http://reviews.gem5.org/r/1987/diff/1/?file=37240#file37240line349>
Spacing around -, also extraneous parentheses around RegIndex
This is actually a cast of a negative 1, not a subtraction... I revamped it to be (I hope) less confusing.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/#review4630
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
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).
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
Steve Reinhardt
2013-08-28 00:10:04 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------

(Updated Aug. 27, 2013, 5:10 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
-------

Changeset 9852:b30933fc9697
---------------------------
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 (updated)
-----

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
Steve Reinhardt
2013-08-28 00:12:41 UTC
Permalink
-----------------------------------------------------------
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 (updated)
-------

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 (updated)
-----

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
Andreas Hansson
2013-08-28 07:34:41 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1987/#review4663
-----------------------------------------------------------

Ship it!


Ship It!

- Andreas Hansson
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1987/
-----------------------------------------------------------
(Updated Aug. 28, 2013, 12:12 a.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).
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
Loading...