Setting register count config parameters to a low value (usually 37 or less for GP or FP, but could be much higher) while micro-operations are enabled can cause the simulation to not progress. This leads to a memory leak, but is not caused by one.
This is an unlikely case for a realistic CPU design, hence not finding this until now.
The issue occurs when we have an instruction with micro-operations that require more physical registers of a specific type to rename than we have after architectural registers (uops required > physical registers - architectural registers). A solution to this would be to halt and provide a useful error when we detect an instruction has more micro-operations of a given type than the spare registers of the same type, stating that the chosen architecture can not support the micro-operation setup. This is a very similar fix to #399 and can likely be merged.
Setting register count config parameters to a low value (usually 37 or less for GP or FP, but could be much higher) while micro-operations are enabled can cause the simulation to not progress. This leads to a memory leak, but is not caused by one.
This is an unlikely case for a realistic CPU design, hence not finding this until now.
The issue occurs when we have an instruction with micro-operations that require more physical registers of a specific type to rename than we have after architectural registers (
uops required > physical registers - architectural registers). A solution to this would be to halt and provide a useful error when we detect an instruction has more micro-operations of a given type than the spare registers of the same type, stating that the chosen architecture can not support the micro-operation setup. This is a very similar fix to #399 and can likely be merged.