FastRegAlloc: Fix implicit operands not rewritten
authorGaëtan Bossu <gaetan.bossu@amd.com>
Tue, 16 May 2023 07:22:22 +0000 (09:22 +0200)
committerQuentin Colombet <quentin.colombet@gmail.com>
Tue, 16 May 2023 07:49:20 +0000 (09:49 +0200)
commitc4a872badb538b53ce93c113dbb6be5b40a95d54
tree687f77962d679affbb1a094de2c6bda56ae04cfa
parente4fd46b511b4a2729e5e1f792e741a88b4c5b935
FastRegAlloc: Fix implicit operands not rewritten

This patch fixes a potential crash due to RegAllocFast not rewriting virtual
registers. This essentially happens because of a call to
MachineInstr::addRegisterKilled() in the process of allocating a "killed" vreg.
The former can eventually delete implicit operands without RegAllocFast
noticing, leading to some operands being "skipped" and not rewritten to use
physical registers.

Note that I noticed this crash when working on a solution for tying a register
with one/multiple of its sub-registers within an instruction. (See problem
description here:
https://discourse.llvm.org/t/pass-to-tie-an-output-operand-to-a-subregister-of-an-input-operand/67184).

Aside from this fix, I believe there could be further improvements to the
RegAllocFast when it comes to instructions with multiple uses of a same virtual
register. You can see it in the added test where the implicit uses have been
re-written in a somewhat surprising way because of phase ordering. Ultimately,
when allocating vregs for an instruction, I believe we should iterate on the
vregs it uses (and then process all the operands that use this vregs), instead
of directly iterating on operands and somewhat assuming each operand uses a
different vreg. This would in the end be quite close to what
greedy+virtregrewriter does. If that makes sense, I would probably spin off
another patch (after I get more familiar with RegAllocFast).

Differential Revision: https://reviews.llvm.org/D145169
llvm/lib/CodeGen/RegAllocFast.cpp
llvm/test/CodeGen/ARM/regalloc-fast-rewrite-implicits.mir [new file with mode: 0644]