The goal of this patch is to improve the throughput analysis in llvm-mca for the case where instructions in the input assembly sequence perform partial register writes.
On x86, partial register writes are quite difficult to model, mainly because different processors tend to implement different register merging schemes in hardware.
When the code contains partial register writes, the IPC (instructions per cycles) estimated by llvm-mca tends to diverge quite significantly from the observed IPC (using perf).
Modern AMD processors (at least, from Bulldozer onwards) don't rename partial registers. Quoting Agner Fog's microarchitecture.pdf:
The processor always keeps the different parts of an integer register together. For example, AL and AH are not treated as independent by the out-of-order execution mechanism. An instruction that writes to part of a register will therefore have a false dependence on any previous write to the same register or any part of it.
This patch is a first important step towards improving the analysis of partial register updates.
This patch changes the semantic of RegisterFile descriptors in tablegen, and teaches llvm-mca how to identify false dependences in the presence of partial register writes (for more details: see the new code comments in include/Target/TargetSchedule.h - class RegisterFile).
This patch doesn't address the case where a write to a part of a register is followed by a read from the whole register.
On Intel chips, high8 registers (AH/BH/CH/DH)) can be stored in separate physical registers. However, a later (dirty) read of the full register (example: AX/EAX) triggers a merge uOp, which adds extra latency (and potentially affects the pipe usage).
This is a very interesting article about partial register writes on Intel chips here: https://stackoverflow.com/questions/45660139/how-exactly-do-partial-registers-on-haswell-skylake-perform-writing-al-seems-to
In future, the definition of RegisterFile can be extended with extra information that may be used to identify cases where a register read is slowed down by a merge of a partial write.
Please let me know if okay to commit.
-Andrea
This should probably be a TODO.
"Software Optimization Guide for AMD Family 17h Processors"
http://developer.amd.com/wordpress/media/2013/12/55723_SOG_Fam_17h_Processors_3.00.pdf
"34 Microarchitecture of AMD Family 17h Processor Chapter 2"
"2.11 Floating-Point Unit"
So maybe having one single DispatchWidth per ProcResGroup and using that for
both the dispatch and renaming is the way to go.