By: Stubabe (nospam.delete@this.nospam.com), November 14, 2012 1:43 pm
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on November 14, 2012 6:41 am wrote:
> anon (anon.delete@this.anon.com) on November 14, 2012 5:10 am wrote:
> [snip]
> > When it is said that the front-end handles simple reg,reg moves
> > and saves OOOE resources, what does this mean exactly?
> >
> > Presumably such instruction has to be at least tracked in the ROB somehow. So it may save a physical
> > register and an execution unit, but it's not entirely eliminated from OOOE part. Or am I way off base?
>
> A move that occurs immediately before an instruction which uses the destination of the move
> as a source/destination can effectively be fused with the later instruction. E.g.:
>
> mov R9 add R10
> can be transformed into:
>
> add R10
> which could occupy a single ROB entry. (Note that each instruction need not maintain a unique
> ROB entry; ISTR that POWER4 hold up to four instructions plus a branch in each ROB entry.)
>
> Unrestricted move elimination would be more complex. However, even if such requires a ROB entry, it removes
> the move from the dependence chain--zero-cycle move--(as well as saving a register, temporary use of a scheduler
> slot, execution unit use, and possibly register file reads). Avoiding execution saves power, of course.
>
>
Surely it's just handled by the Register Alias Table?
i.e.
if PR100 (physical register) holds R9, PR90 holds R15 and PR101 is the next free reg
Without MOV elimination
-----------------------
MOV R10 <- R9
R10 would allocate PR101 and R9 renames to PR100
ADD R10, R10 R15
R10 would allocate PR102, R10 renames to PR101 and R15 to PR90
so the sequence becomes:
uMOV PR101, PR100
uADD PR102, PR101, PR90
With MOV elimination
--------------------
MOV R10 <- R9
R10 would now rename to PR100 as well as R9
ADD R10, R10 R15
R10 would allocate PR101, R10 renames to PR100 and R15 to PR90
so the sequence becomes:
uADD PR101, PR100, PR90
This way the is no need to fuse adjacent instructions, R10 can have multiple dependences and the instruction can get NOPed
> anon (anon.delete@this.anon.com) on November 14, 2012 5:10 am wrote:
> [snip]
> > When it is said that the front-end handles simple reg,reg moves
> > and saves OOOE resources, what does this mean exactly?
> >
> > Presumably such instruction has to be at least tracked in the ROB somehow. So it may save a physical
> > register and an execution unit, but it's not entirely eliminated from OOOE part. Or am I way off base?
>
> A move that occurs immediately before an instruction which uses the destination of the move
> as a source/destination can effectively be fused with the later instruction. E.g.:
>
> mov R9 add R10
> can be transformed into:
>
> add R10
> which could occupy a single ROB entry. (Note that each instruction need not maintain a unique
> ROB entry; ISTR that POWER4 hold up to four instructions plus a branch in each ROB entry.)
>
> Unrestricted move elimination would be more complex. However, even if such requires a ROB entry, it removes
> the move from the dependence chain--zero-cycle move--(as well as saving a register, temporary use of a scheduler
> slot, execution unit use, and possibly register file reads). Avoiding execution saves power, of course.
>
>
Surely it's just handled by the Register Alias Table?
i.e.
if PR100 (physical register) holds R9, PR90 holds R15 and PR101 is the next free reg
Without MOV elimination
-----------------------
MOV R10 <- R9
R10 would allocate PR101 and R9 renames to PR100
ADD R10, R10 R15
R10 would allocate PR102, R10 renames to PR101 and R15 to PR90
so the sequence becomes:
uMOV PR101, PR100
uADD PR102, PR101, PR90
With MOV elimination
--------------------
MOV R10 <- R9
R10 would now rename to PR100 as well as R9
ADD R10, R10 R15
R10 would allocate PR101, R10 renames to PR100 and R15 to PR90
so the sequence becomes:
uADD PR101, PR100, PR90
This way the is no need to fuse adjacent instructions, R10 can have multiple dependences and the instruction can get NOPed
