This reverts commit aa65f93b71dee8cacb22be1957673c8be6a3ec24.
This relands commit 8cc83b66e20e72cdb3bb5fbd549c941797b0e0c9.
It looks like this was a transitive include issue.
This patch adjusts the mlregalloc-max-cascade flag (renaming it to
mlregalloc-max-eviction-count) to actually count evictions rather than
just looking at the cascade number. The cascade number is not very
representative of how many times a LR has been evicted, which can lead
to some problems in certain cases, where we might end up with many
eviction problems where we have now masked off all the interferences and
are forced to evict the candidate.
This is probably what I should've done in the first place. No test case
as this only shows up in quite large functions post ThinLTO and it would
be hard to construct something that would serve as a nice regression
test without being super brittle. I've tested this on the pathological
cases that we have come across so far and it works.
Fixes#122829
A previous PR introduced a threshold where we would mask out a LR that
had been evicted a certain number of times to combat pathological
compile time cases with a somewhat adversarial model. However, this
patch did not take into account urgent LRs which led to compilation
failures when greedy would expect us to provide an eviction and we could
not due to the newly introduced logic.
This patch adds a threshold flag, -mlregalloc-max-cascade, to prevent
live ranges from being evicted more than is necessary.
After deploying a new regalloc model, we ran into some pathological
cases where the model decided it wanted to ping-pong evictions, taking
up a large amount of compile time. This threshold is mostly a stop gap
while we continue to investigate other solutions and work on
minimizing/constructing test cases.
- Add `MachineBlockFrequencyAnalysis`.
- Add `MachineBlockFrequencyPrinterPass`.
- Use `MachineBlockFrequencyInfoWrapperPass` in legacy pass manager.
- `LazyMachineBlockFrequencyInfo::print` is empty, drop it due to new
pass manager migration.
