By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), November 15, 2012 12:50 pm
Room: Moderated Discussions
Stubabe (nospam.delete@this.nospam.com) on November 15, 2012 11:38 am wrote:
[snip]
> I'm sorry, but the uop fusion thing looks messy for
> the hardware to track to me, especially if multiple dependencies are present.
The µop fusion form of move elimination is for a move whose sole consumer is the next instruction, which uses the same destination register name (i.e., a move that is use to emulate an instruction with a destination distinct from its source operands--a significant fraction of moves are for this purpose). This means that only one µop needs to be handled by the renamer. This might expand the size of µops between the decode and renamer.
Renamer-based move elimination is more flexible, of course, and could be used in addition to or instead of µop fusion.
[snip]
> I'm sorry, but the uop fusion thing looks messy for
> the hardware to track to me, especially if multiple dependencies are present.
The µop fusion form of move elimination is for a move whose sole consumer is the next instruction, which uses the same destination register name (i.e., a move that is use to emulate an instruction with a destination distinct from its source operands--a significant fraction of moves are for this purpose). This means that only one µop needs to be handled by the renamer. This might expand the size of µops between the decode and renamer.
Renamer-based move elimination is more flexible, of course, and could be used in addition to or instead of µop fusion.
