[all-commits] [llvm/llvm-project] 91aac7: AMDGPU: Handle s_add_u32 in eliminateFrameIndex (#...

[Matt Arsenault via All-commits]

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

  Changed paths:
    M llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/insertelement-stack-lower.ll
    A llvm/test/CodeGen/AMDGPU/eliminate-frame-index-s-add-u32.mir
    M llvm/test/CodeGen/AMDGPU/flat-scratch-svs.ll
    M llvm/test/CodeGen/AMDGPU/frame-index-elimination.ll
    M llvm/test/CodeGen/AMDGPU/frame-index.mir

  Log Message:
  -----------
  AMDGPU: Handle s_add_u32 in eliminateFrameIndex (#129628)

We can fold frame indexes directly into existing immediate operands,
just like is already done for s_add_i32. We happen to use s_add_i32 in
the 32-bit add case, but s_add_u32 appears in the a 64-bit add sequence
of a flat pointer if an addrpacecast source is a frame index.

This avoids, but does not address a failure exposed after
a3165398db0736588daedb07650195502592e567 where two literal operands
end up in the final instruction. The underlying issue still exists for
some instructions without special handling in eliminateFrameIndex.



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