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

[Quentin Colombet via Phabricator via llvm-commits]

qcolombet added a comment.

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

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96015