[PATCH] D96015: [RegAllocFast] Handle case where operand of copy cannot be assigned.

[Amara Emerson via Phabricator via llvm-commits]

aemerson added a comment.

In D96015#2555938 <https://reviews.llvm.org/D96015#2555938>, @qcolombet wrote:

> To elaborate on the answer:
>
>> why is it any more job of the scheduler to keep the live ranges small for the sake of the allocator?
>
> Because:
>
> 1. the allocator assumes a fixed schedule, it keeps the live ranges small by splitting/spilling them (only spilling for the fast allocator)
> 2. the live-ranges that are causing problems in that example are physical registers, which the allocator cannot touch, so we cannot split or spill them

Ok, with 2. it's clearer now why this is a problem.

> Therefore, the only way to make this input colorable is by changing the schedule, which by #1 is not what the allocator does and knows to handle to be fair.
>
> This patch adds some mechanics to teach the allocator how to do some re-scheduling in a very specific case, and I argue that we are setting a dangerous path. E.g., what if instead of a copy we have `physreg = add %v, #1`, then the allocator would fail exactly the same way.
>
> Long story short, with today's capabilities and intended design, the input is invalid.

It sounds like we need to have the fast-RA be able to defer to the more sophisticated allocators in certain cases, but I don't think it's possible to do with the existing pass manager.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96015