[all-commits] [llvm/llvm-project] 033701: X86: Remove hack in shouldRewriteCopySrc for subre...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/x86/remove-shouldRewriteCopySrc-hack
  Home:   https://github.com/llvm/llvm-project
  Commit: 033701bdc299968e0c82ed888159f8b9ee6ca526
      https://github.com/llvm/llvm-project/commit/033701bdc299968e0c82ed888159f8b9ee6ca526
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-02-05 (Wed, 05 Feb 2025)

  Changed paths:
    M llvm/lib/CodeGen/TargetRegisterInfo.cpp
    M llvm/lib/Target/X86/X86RegisterInfo.cpp
    M llvm/lib/Target/X86/X86RegisterInfo.h
    A llvm/test/CodeGen/X86/pr41619_reduced.mir

  Log Message:
  -----------
  X86: Remove hack in shouldRewriteCopySrc for subregister handling

In the problematic situation fixed in 61e556d2bdf3fa0a10dbaadd2dd03d01c341bd27,
shouldRewriteCopySrc is called with identical register class arguments,
but one has a subregister index. This was very surprising to me,
and it probably shouldn't be valid for it to occur. It happens in cases
with uncoalescable copies where the register class changes, and further
up the chain there is a subregister operand. We could possibly just
skip over uncoalsecable instructions in the chain rather than letting
this query deal with it (or pre-filter the obvious subreg with same
class case).

The generic implementation is supposed to account for checking for
valid subregisters by checking getMatchingSuperRegClass already,
but that was bypassed by the early exit for exact class match.

Also adds a reduced mir test demonstrating the exact problematic
case.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications