[all-commits] [llvm/llvm-project] 63d1d3: RegAllocGreedy: Avoid overflowing priority bitfields

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 63d1d37d35e513632e9d4fcc1910ed4e9e3525d0
      https://github.com/llvm/llvm-project/commit/63d1d37d35e513632e9d4fcc1910ed4e9e3525d0
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2022-09-15 (Thu, 15 Sep 2022)

  Changed paths:
    M llvm/include/llvm/CodeGen/TargetRegisterInfo.h
    M llvm/include/llvm/Target/Target.td
    M llvm/lib/CodeGen/RegAllocGreedy.cpp
    M llvm/lib/Target/PowerPC/PPCRegisterInfoMMA.td
    M llvm/utils/TableGen/CodeGenRegisters.cpp
    M llvm/utils/TableGen/CodeGenRegisters.h
    M llvm/utils/TableGen/RegisterInfoEmitter.cpp

  Log Message:
  -----------
  RegAllocGreedy: Avoid overflowing priority bitfields

The class priority is expected to be at most 5 bits before it starts
clobbering bits used for other fields. Also clamp the instruction
distance in case we have millions of instructions.

AMDGPU was accidentally overflowing into the global priority bit in
some cases. I think in principal we would have wanted this, but in the
cases I've looked at, it had the counter intuitive effect and
de-prioritized the large register tuple.

Avoid using weird bit hack PPC uses for global priority. The
AllocationPriority field is really 5 bits, and PPC was relying on
overflowing this to 6-bits to forcibly set the global priority
bit. Split this out as a separate flag to avoid having magic behavior
for values above 31.