[all-commits] [llvm/llvm-project] 92e3cd: X86: Remove hack in shouldRewriteCopySrc for subre...
Matt Arsenault via All-commits
all-commits at lists.llvm.org
Wed Feb 5 08:25:26 PST 2025
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 92e3cd70698c2e06787500694c6a962d9228676d
https://github.com/llvm/llvm-project/commit/92e3cd70698c2e06787500694c6a962d9228676d
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 (#125224)
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
More information about the All-commits
mailing list