[all-commits] [llvm/llvm-project] e995e3: [MachinePipeliner] Handle failing constrainRegClass

[David Green via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e995e34469be69d867dcf67935faead59feee9b1
      https://github.com/llvm/llvm-project/commit/e995e34469be69d867dcf67935faead59feee9b1
  Author: David Green <david.green at arm.com>
  Date:   2022-06-19 (Sun, 19 Jun 2022)

  Changed paths:
    M llvm/lib/CodeGen/MachineLoopUtils.cpp
    M llvm/lib/CodeGen/ModuloSchedule.cpp
    A llvm/test/CodeGen/Thumb2/mve-pipelineloops.ll

  Log Message:
  -----------
  [MachinePipeliner] Handle failing constrainRegClass

The included test hits a verifier problems as one of the instructions:
```
%113:tgpreven, %114:tgprodd = MVE_VMLSLDAVas16 %12:tgpreven(tied-def 0), %11:tgprodd(tied-def 1), %7:mqpr, %8:mqpr, 0, $noreg, $noreg
```
Has two inputs that come from different PHIs with the same base reg, but
conflicting regclasses:
```
%11:tgprodd = PHI %103:gpr, %bb.1, %16:gpr, %bb.2
%12:tgpreven = PHI %103:gpr, %bb.1, %17:gpr, %bb.2
```

The MachinePipeliner would attempt to use %103 for both the %11 and %12
operands in the prolog, constraining the register class to the common
subset of both. Unfortunately there are no registers that are both odd
and even, so the second constrainRegClass fails. Fix this situation by
inserting a COPY for the second if the call to constrainRegClass fails.

The register allocation can then fold that extra copy away. The register
allocation of Q regs changed with this test, but the R regs were the
same and no new instructions are needed in the final assembly.

Differential Revision: https://reviews.llvm.org/D127971