[all-commits] [llvm/llvm-project] d70a17: AMDGPU: Handle s_add_u32 in eliminateFrameIndex

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/eliminateFrameIndex-s-add-u32
  Home:   https://github.com/llvm/llvm-project
  Commit: d70a17f970787b9d19206481e5825ae5f5c8de27
      https://github.com/llvm/llvm-project/commit/d70a17f970787b9d19206481e5825ae5f5c8de27
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-03-04 (Tue, 04 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

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