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

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8476a5d480304bf7bd934c660a159e1c6906a69d
      https://github.com/llvm/llvm-project/commit/8476a5d480304bf7bd934c660a159e1c6906a69d
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-03-04 (Tue, 04 Mar 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 (#122110)

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