llvm-project.git/llvm/test/CodeGen/AMDGPU/local-stack-alloc-block-sp-reference.ll, branch users/nico/python-2

AMDGPU: Make frame index folding logic consistent with eliminateFrameIndex (#129633)

2025-03-05T03:09:30+00:00

This adds handling of s_add_u32, which is handled and removes handling of
s_or_b32 and s_and_b32, which are not. I was working on handling them
in #102345, but need to finish that patch. This fixes a regression
exposed by a3165398db0736588daedb07650195502592e567 where the
final instruction would use two literals.

AMDGPU: Fix overly conservative immediate operand check (#127563)

2025-02-27T01:42:09+00:00

The real legality check is peformed later anyway, so this was
unnecessarily blocking immediate folds in handled cases.

This also stops folding s_fmac_f32 to s_fmamk_f32 in a few tests,
but that seems better. The globalisel changes look suspicious,
it may be mishandling constants for VOP3P instructions.

[AMDGPU] Restore SP from saved-FP or saved-BP (#124007)

2025-01-24T13:43:40+00:00

Currently, the AMDGPU backend bumps the Stack Pointer 
by fixed size offsets in the prolog of device functions, and 
restores it by the same amount in the epilog.
Prolog:
sp += frameSize

Epilog:
sp -= frameSize

If a function has dynamic stack realignment,
Prolog:
sp += frameSize + max_alignment

Epilog:
sp -= frameSize + max_alignment

These calculations are not optimal in case of dynamic 
stack realignment, and completely fail in case of 
dynamic stack readjustment.
This patch uses the saved Frame Pointer to restore SP. 
Prolog:
fp = sp
sp += frameSize

Epilog:
sp = fp

In case of dynamic stack realignment, SP is restored from 
the saved Base Pointer. 
Prolog:
fp = sp + (max_alignment - 1)
fp = fp & (-max_alignment)
bp = sp
sp += frameSize + max_alignment

Epilog:
sp = bp

(Note: The presence of BP has been enforced in case of any 
dynamic stack realignment.)

---------

Co-authored-by: Pravin Jagtap 
Co-authored-by: Matt Arsenault

AMDGPU: Fix using illegal VOP3 literal in frame index elimination (#115747)

2024-11-13T16:01:01+00:00

AMDGPU: Default to selecting frame indexes to SGPRs (#115060)

2024-11-09T03:01:59+00:00

Only select to a VGPR if it's trivally used in VGPR only contexts.
This fixes mishandling frame indexes used in SGPR only contexts,
like inline assembly constraints.

This is suboptimal in the common case where the frame index
is transitively used by only VALU ops. We make up for this by later
folding the copy to VALU plus scalar op in SIFoldOperands.

Reapply "[AMDGPU] Still set up the two SGPRs for queue ptr even it is COV5 (#112403)"

2024-11-09T01:21:16+00:00

This reverts commit ca33649abe5fad93c57afef54e43ed9b3249cd86.

Revert "[AMDGPU] Still set up the two SGPRs for queue ptr even it is COV5 (#112403)"

2024-11-08T21:36:35+00:00

This reverts commit e215a1e27d84adad2635a52393621eb4fa439dc9 as it broke both
hip and openmp buildbots.

[AMDGPU] Still set up the two SGPRs for queue ptr even it is COV5 (#112403)

2024-11-08T18:05:35+00:00

AMDGPU: Try to reuse dest reg for s_add_i32 frame indexes (#111201)

2024-10-07T14:01:24+00:00

Hack around the register scavenger doing the wrong thing.
It does not find the result register as available in the
case the frame index add isn't also reading the dest register.
This is the quick fix for a regression where the scavenge would
create a broken spill of SGPR to memory. I believe this is still
broken for cases we cannot use the result register.

I'm confused about what position the scavenger iterator
is supposed to be in, and what RestoreAfter is for. The scavenger
is missing a full set of forward/backward APIs and there seems
to be an off by one somewhere.

AMDGPU: Handle folding frame indexes into s_add_i32 (#101694)

2024-08-22T05:16:37+00:00

This does not yet enable producing direct frame index
references in s_add_i32, only the lowering.