[all-commits] [llvm/llvm-project] 57f936: SplitKit: Fix rematerialization undoing subclass b...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/splitkit-no-remat-if-increases-constraints
  Home:   https://github.com/llvm/llvm-project
  Commit: 57f9368d44b4a3406b41a62daffe5448ad722633
      https://github.com/llvm/llvm-project/commit/57f9368d44b4a3406b41a62daffe5448ad722633
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-01-08 (Wed, 08 Jan 2025)

  Changed paths:
    M llvm/lib/CodeGen/SplitKit.cpp
    M llvm/lib/CodeGen/SplitKit.h
    A llvm/test/CodeGen/AMDGPU/splitkit-do-not-undo-subclass-split-with-remat.mir
    M llvm/test/CodeGen/X86/eq-or-eq-range-of-2.ll
    M llvm/test/CodeGen/X86/fptosi-sat-vector-128.ll
    M llvm/test/CodeGen/X86/fptoui-sat-vector-128.ll
    M llvm/test/CodeGen/X86/statepoint-invoke-ra-enter-at-end.mir

  Log Message:
  -----------
  SplitKit: Fix rematerialization undoing subclass based split

This fixes an allocation failure in the new test.

In cases where getLargestLegalSuperClass can inflate the register class,
rematerialization could effectively undo a split which was done to inflate
the register class, if the defining instruction can only write a subclass
and the use can read the superclass.

Some of the x86 tests changes look like improvements, but some are
likely regressions.

I'm not entirely sure this is the correct place to fix this. It also
seems more complicated than necessary, but the decision to change
the register class is far removed from the point where the decision
to split the virtual register is made. I'm also also not sure if this
should be considering the register classes of all the use indexes
in getUseSlots, rather than just checking if this use index instruction
reads the register.



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