Ignore Renaming of x0

[aarongchan]

Fix renaming to skip renaming of x0 outlined in https://github.com/riscv-software-src/riscv-perf-model/issues/118.

Changes:

• renameInstructions_() now checks if a source is x0, if it is and is a data operand for a LSU operation, we still create a data register for it, as we need to check in LSU for x0 before issuing instruction
• Added a boolean x0 field to Reg struct in RenameData that tracks if a data register is an x0 instruction. This helps on reclamation of rename credits in getAckFromROB_() to make sure we don't decrement for an x0 data register
• Updated logic to handle for destination reclamation in getAckFromROB_() to ensure when we reclaim credits/freelist registers/references, we don't process them for x0 destinations
• Fixed initial allocation of freelist registers for RF_INTEGER to only map registers for x1 - x31, before we were mapping from x0 - x31, so we should technically see a performance improvement as we gained 1 extra freelist register from not renaming x0

[danbone]

Missing logic here: https://github.com/riscv-software-src/riscv-perf-model/blob/55661600abe6604d3fc369da398e7677efdb1b1c/core/Rename.cpp#L197-L201

[danbone]

This change seems a bit convoluted, would it not be better to refactor the allocation and freeing into separate functions, and act differently when the input register is X0.

Also, I can't find out where the scoreboard will always ready x0 reads? https://github.com/riscv-software-src/riscv-perf-model/blob/55661600abe6604d3fc369da398e7677efdb1b1c/core/Rename.cpp#L292-L297

[aarongchan]

This change seems a bit convoluted, would it not be better to refactor the allocation and freeing into separate functions, and act differently when the input register is X0.

Also, I can't find out where the scoreboard will always ready x0 reads?

https://github.com/riscv-software-src/riscv-perf-model/blob/55661600abe6604d3fc369da398e7677efdb1b1c/core/Rename.cpp#L292-L297

The scoreboard is marked here: https://github.com/riscv-software-src/riscv-perf-model/blob/55661600abe6604d3fc369da398e7677efdb1b1c/core/Rename.cpp#L107

And because we bypass any destinations of x0, we can assume the scoreboard is always marked ready. An alternative I'm considering is just storing whether a data operand in a LSU operation is x0, if so we just pass it through, without checking the scoreboard.

With regards to refactoring, my initial thoughts were to keep as much of the original code as possible, but am considering ways to refactor it currently. Allocate and freeing are currently separated with regards to renameInstructions_() and getAckFromROB_(), but are you saying to have a more generic functions that we pass the operands through?