[llvm] [RegAlloc] Add register allocation anti-hints infrastructure (PR #218071)

Lukas Sommer via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 8 01:41:53 PDT 2026


https://github.com/sommerlukas commented:

> > Implementation looks good to me, but there might be an issue with how much of the order that was reshuffled based on anti-hints is actually iterated by register allocators, see here:
> > https://github.com/llvm/llvm-project/blob/945e3e825b3ee88a8c1fed0da2dc88d6b2114e37/llvm/lib/CodeGen/RegAllocGreedy.cpp#L684-L690
> > 
> > If `getLastCostChange` isn't updated after anti-hints (which I don't think it is), we might not iterate all registers that meet the cost criteria after reshuffling based on anti-hints.
> 
> IIRC, I don't think it matters because these costs are either per physical register (`RegCosts`) or per RegisterClass (`getLastCostChange`). None of that is affected by the allocation `Order`.

Yes, the cost computation is not affected by the allocation order. However, as the anti-hints change the order, it changes which registers will be considered. 

Imagine we have register class with four registers and costs: `r0 = 0, r1 = 0, r2 = 1, r3 = 1`. The last cost change here is at index 2, so `OrderLimit` would be 2 in this case. 

Now, if `r1` is anti-hinted, the order is changed to `r0, r2, r3, r1`. Due to the `OrderLimit`, we would only visit `r0` and `r2` in this case. This may be intended, but I wanted to make sure that we're OK with limiting the iteration over registers like this.

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


More information about the llvm-commits mailing list