[llvm] [RFC][MC] Cache MCRegAliasIterator (PR #93510)

[Pierre van Houtryve via llvm-commits]

Pierre-vh wrote:

> > > Maybe it's fine for a stopgap
> > 
> > 
> > It's what I think too, but as the saying goes, there's nothing as permanent as a temporary solution. I'm not comfortable landing this unless everyone is sure it'd beneficial even if we end up removing most uses of RegAlias iterator at some point.
> > I personally think it is beneficial anyway because:
> > 
> > * If we remove RegAlias iterator as a whole at some point, then this just goes away.
> > * If we can't remove it and there are still some uses left in the hot path, caching is always a good thing.
> 
> Agree on everything that was discussed.
> 
> Just one comment on the caching (disclaimer I haven't looked at the implementation), how stable is it from run-to-run?
> 
> I want to make sure we do not create non-determinism.

The current implementation should be perfectly stable, `sort + unique` is used and register IDs are tablegen-erated so they're consistent.
If we make caching more complex, like say only cache when N hits happen, or above certain thresholds or with frequent cache clears, then it might introduce some non-determinism because the cached/uncached version return registers in a different order (and the uncached version returns them multiple times).

> Agree on everything that was discussed.

To clarify, do you agree that caching is valuable anyway (so this diff could land), but we should still make efforts to move away from using register aliases for liveness?


https://github.com/llvm/llvm-project/pull/93510