This patch adds a new CLI option to the MC layer called
`-sched-model-reservation-station-scale-factor` that enables to scale
the buffer size of all reservation stations (RS) for resources in the
scheduling model by a positive `float` factor. It is limited to scaling
OOO resources, and not special buffer sizes (-1,0,1), and similarly it
is only allowed to produce OOO resources.
This can be used for example to try find headroom in post-RA instruction
scheduling for OOO cores - e.g. scale RS size by 2 and observe IPC
gains, if so the code may be senetitive to the schedule and we may do
better.
Note: Currently, BufferSize for LSU resources defines the reservation
station (RS), but if present also the ld/st queue size, which just
points to the provided LSU resource. Thus, we currently scale them both
in lockstep, until we have an independent ld/st queue model.
The implementation adds a new method
`MCSchedule::getResourceBufferSize()` that calculates the buffer size
and exits early by default. It is wrapped on `TargetSchedule` for
CodeGen, or other users call it directly. For `ResourceState` we add a
scheduling model context to the constructor. `LSUnit` still uses
`BufferSize` directly, as it has inline logic for load/store queues
handling. So is `llvm/lib/Target/SystemZ/SystemZHazardRecognizer.cpp`
which is target specific. Testing through `llvm-mca` debug output. We
could syntesize a BB that is sensitive to the schedule and check an IPC
improvement, but it would be more compilated.
This only impacts llvm-mca at the moment. However, I think it should
logically belong to the MC layer, which owns the scheduling model
infrastructure, as the option is coupled to the model and not MCA. Thus,
this patch adds it speculatively to the MC layer, e.g. so that we can
easily observe how a RS-based scheduler performs for next-generation
larger-RS target without re-coding and re-building LLVM. Following up,
we may even move other such options to from the `llvm-mca` tool to the
MC library like dispatch width etc.
c5e2c25988