[all-commits] [llvm/llvm-project] 941e59: 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: 941e598aab27b18d1c92114be3f0e3949401f5b0
      https://github.com/llvm/llvm-project/commit/941e598aab27b18d1c92114be3f0e3949401f5b0
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-02-27 (Thu, 27 Feb 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