This is an archive of the discontinued LLVM Phabricator instance.

RegAlloc: Fix verifier error after failed allocation
AcceptedPublic

Authored by arsenm on Mar 28 2022, 2:17 PM.

Details

Reviewers
qcolombet
MatzeB
Summary

In some cases after reporting an allocation failure, this would fail
the verifier. It picks the first allocatable register and assigns it,
but didn't update the liveness appropriately. When VirtRegRewriter
relied on the liveness to set kill flags, it would incorrectly add
kill flags if there was another overlapping kill of the virtual
register.

We can't properly assign the register to an overlapping range, so
break the liveness of the failing register (and any other interfering
registers) instead. Give the virtual register dummy liveness by
effectively deleting all the uses by setting them to undef.

The edge case not tested here which I'm worried about is if the read
of the register is a def of a subregister. I've been unable to come up
with a test where this occurs.

Diff Detail

Event Timeline

arsenm created this revision.Mar 28 2022, 2:17 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 2:17 PM
arsenm requested review of this revision.Mar 28 2022, 2:17 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 2:17 PM
Herald added a subscriber: wdng. · View Herald Transcript

Hi @arsenm,

The patch itself looks good but I wonder if we could maybe take a simpler road:
Could we assign register zero (noreg) to this failed vreg?

Cheers,
-Quentin

Hi @arsenm,

The patch itself looks good but I wonder if we could maybe take a simpler road:
Could we assign register zero (noreg) to this failed vreg?

Cheers,
-Quentin

The verifier doesn't like that at all since it doesn't have an associated class. Plus every target would have to handle encoding it as something in the end

The verifier doesn't like that at all since it doesn't have an associated class. Plus every target would have to handle encoding it as something in the end

I was hoping that the compiler would stop before we get to the encoding phase.
I.e., I would have expected that any "emit error" would stop the compiler pipeline after the current pass because at this point we are in an unsupported state.

Oh well, updating live-intervals it is :).

qcolombet accepted this revision.Sep 19 2022, 4:14 PM

Forgot to approve in my last comment.

This revision is now accepted and ready to land.Sep 19 2022, 4:14 PM