You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if Micro-Operations are enabled and we encounter a case where the number of destination registers required to rename all micro-operations is greater than the spare physical registers set (total registers - architecture registers), then we get indefinitely stuck in a case where some microops have been commited to the reorder buffer, stopping an unwind, and the next micro-op stalls waiting for an available register which can never become available.
This can impact an unbounded set of register parameters, subject to the micro-operations specified.
A few things make this a hard problem to solve:
We don't easily know how many registers a split macro-op will need when it arrives at the rename unit
We must either split all instructions, or none
These instructions may be incorrectly speculated, but lead to the same issue
We must first detect when this case has been hit. One proposed solution is tallying per macro-op how many destination registers of each type are required for each uop that reaches the rename unit. If we detect this tally exceeds the spare physical registers, then we have hit this case.
Once the case has been hit, we must then raise a meaningful exception. This potentially requires some reworking such that the rename unit can raise an exception, and that we will have access to enough information (the macro op, pneumonic, and instruction address).
The text was updated successfully, but these errors were encountered:
Currently, if
Micro-Operations
are enabled and we encounter a case where the number of destination registers required to rename all micro-operations is greater than the spare physical registers set (total registers - architecture registers
), then we get indefinitely stuck in a case where some microops have been commited to the reorder buffer, stopping an unwind, and the next micro-op stalls waiting for an available register which can never become available.This can impact an unbounded set of register parameters, subject to the micro-operations specified.
A few things make this a hard problem to solve:
We must first detect when this case has been hit. One proposed solution is tallying per macro-op how many destination registers of each type are required for each uop that reaches the rename unit. If we detect this tally exceeds the spare physical registers, then we have hit this case.
Once the case has been hit, we must then raise a meaningful exception. This potentially requires some reworking such that the rename unit can raise an exception, and that we will have access to enough information (the macro op, pneumonic, and instruction address).
The text was updated successfully, but these errors were encountered: