[all-commits] [llvm/llvm-project] b21663: SplitKit: Take register class directly from instru...

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b21663cb5ba9d1ba157a8461c55a35b1a8712a43
      https://github.com/llvm/llvm-project/commit/b21663cb5ba9d1ba157a8461c55a35b1a8712a43
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-03-06 (Thu, 06 Mar 2025)

  Changed paths:
    M llvm/lib/CodeGen/SplitKit.cpp
    A llvm/test/CodeGen/ARM/splitkit-remat-regclass-constraint-regression.ll
    M llvm/test/CodeGen/ARM/splitkit.ll
    M llvm/test/CodeGen/X86/fptosi-sat-vector-128.ll
    M llvm/test/CodeGen/X86/fptoui-sat-vector-128.ll
    A llvm/test/CodeGen/X86/splitkit-remat-broken-subreg-constraint.mir
    M llvm/test/CodeGen/X86/statepoint-invoke-ra-enter-at-end.mir

  Log Message:
  -----------
  SplitKit: Take register class directly from instruction definition (#129727)

This fixes an expensive chesk failure after 8476a5d480304. The issue
was essentially that getRegClassConstraintEffectForVReg was not doing
anything useful, sometimes. If the register passed to it is not present
in the instruction, it is a no-op and returns the original classe. The
Edit->getReg() register may not be the register as it appears in either
the use or def instruction. It may be some split register, so take
the register directly from the instruction being rematerialized.

Also directly query the constraint from the def instruction, with a
hardcoded operand index. This isn't ideal, but all the other
rematerialize
code makes the same assumption.

So far I've been unable to reproduce this with a standalone MIR test. In
the
original case, stop-before=greedy and running the one pass is not
working.



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