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

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/regalloc/regression-expensive-checks-splitkit-no-remat-if-increases-constraints
  Home:   https://github.com/llvm/llvm-project
  Commit: 14aeafcf829f93e24eaa6c3aedf988aa404e2a77
      https://github.com/llvm/llvm-project/commit/14aeafcf829f93e24eaa6c3aedf988aa404e2a77
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-03-04 (Tue, 04 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
    M llvm/test/CodeGen/X86/statepoint-invoke-ra-enter-at-end.mir

  Log Message:
  -----------
  SplitKit: Take register class directly from instruction definition

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