[PATCH] D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 4 10:53:46 PST 2022


arsenm added a comment.

In D119973#3359120 <https://reviews.llvm.org/D119973#3359120>, @uabelho wrote:

> In D119973#3358798 <https://reviews.llvm.org/D119973#3358798>, @arsenm wrote:
>
>> I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called
>
> Not sure if it's what you are experiencing, but tryLastChanceRecoloring is broken in a few cases where "complicated" things have happened during the "try" part of it.
>
> If recoloring fails, it tries to restore the state, but it does not restore e.g. splitting of vregs that happened.
>
> So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

I think this is exactly what's happening


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119973/new/

https://reviews.llvm.org/D119973



More information about the llvm-commits mailing list