[AIEX] Minimize Stackslots by Decomposition and only keeping defined parts of the Stack #754

F-Stuckmann · 2026-01-15T16:19:24Z

This PR introduces a stack optimization pipeline.
The core idea is to not spill undef subregisters.

AIESpillDecomposition – Decomposes composite spill instructions (e.g., 256-byte DM spills) into smaller
subreg spills (e.g., 128-byte CM spills) when only some subregs are live. Uses liveness analysis with
LaneBitmask to determine which subregs actually need spilling.
AIEStackSlotMinimization – Analyzes which subregs of spilled registers are actually accessed. When only a
subset is used, it recreates stack slots with smaller sizes. Also separates non-overlapping registers
sharing the same frame index into independent slots.
Frame Object Ordering - Added orderFrameObjects hook in AIEBaseFrameLowering to sort stack objects by alignment (highest first), reducing wasted padding.

Minor Bug fixes along the way:

Moved isLoadFromStackSlot/isStoreToStackSlot implementations from AIE2/AIE2P to a generic AIEBaseInstrInfo
using MachineMemOperand validation.
Added missing intrinsics to AIE2P frame index lowering.

Performance numbers: I am still looking why Frame Object ordering is screwing up.

Core_Compute_Insn_Count_perf_sorted_reduced

Core_PMSize_perf_sorted_reduced_absolute

Core_StackSize_perf_sorted_reduced_absolute

P.S. I will provide combined performance numbers with #735 integrated, because this PR is a mitgation of some unwanted stack increases of 735.

Move opcode-specific switch statements from AIE2InstrInfo and AIE2PInstrInfo to a generic implementation in AIEBaseInstrInfo using MachineMemOperand validation. This provides a more maintainable approach that automatically works with any spill instruction without needing explicit opcode lists.

Add tests covering: - Basic spill decomposition (DM -> CM when only CML live) - 3D iterator spill decomposition - Subreg spill optimization - Crash regression tests - LaneBitmask pollution prevention - Orphan load crash prevention

Decompose composite spill instructions (e.g., DM spills) into smaller subreg spills (e.g., CM spills) when only some subregs are live. This reduces stack usage by eliminating spills of undefined subregs. For example, if a DM register is spilled but only CML is live, we replace the 256-byte DM spill with a 128-byte CM spill. The pass uses a two-phase approach: 1. Analysis Phase: Collect spill/reload info, compute liveness as LaneBitmask 2. Transformation Phase: Decompose instructions, keeping same FI Enabled by default, can be disabled with -aie-stack-minimize=false.

Add tests covering: - Q register spill size preservation (don't increase slot size) - Register renaming with shared FI (offset-based tracking) - Mixed partial/full usage scenarios - Non-overlapping lane separation - Overlapping byte range merging - Neutral cases (no optimization expected) - FI regression crash prevention

Minimize stack slot sizes by analyzing which subregs of spilled registers are actually used. If only a subset of subregs is accessed, we recreate the stack slots with smaller sizes. For example, if a 2048-bit DM register is spilled but only the 1024-bit CML subreg is used, we shrink the stack slot from 256 bytes to 128 bytes. When multiple non-overlapping registers (based on LaneBitmask) are spilled to the same offset, the pass creates separate stack slots for each group. This pass runs after AIESpillDecomposition and completes the stack optimization pipeline enabled by -aie-stack-minimize (default: true).

martien-de-jong · 2026-01-16T09:22:39Z

llvm/lib/Target/AIE/AIEBaseInstrInfo.cpp

+      FrameIndex = MI.getOperand(1).getIndex();
+      return MI.getOperand(0).getReg();
+    }
+  }


I hope that stack loads have exactly one MMO which is a Load, and I would feel comforted if that were asserted.
I'm also not sure where these functions are used and whether it requires completeness in identifying all stack loads, whether stack loads from user stack objects always have their MMO's set correctly.
I'm also convinced that there are quintillion combinations of stack use, of which only a fraction is tested in practice and that we should hence be cautious. It is great to have this unified, granting us the possibility to concentrate all sanity checking in one place.

martien-de-jong · 2026-01-16T09:35:54Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterInfo.cpp

    // Note that LDB path does not support SPILL instructions

+  case AIE2P::LDA_dms_lda_spill:
+  case AIE2P::ST_dms_sts_spill:


nit: you call these intrinsics in your commit comment

martien-de-jong · 2026-01-16T09:37:33Z

llvm/test/CodeGen/AIE/aie2p/ra/spill-decomposition-3d.mir

+# RUN: llc -mtriple=aie2p --run-pass=none -o - -verify-machineinstrs %s | FileCheck %s
+
+---
+name:            _Z11conv2d_bf16ILh1EL5act_t0E8bfloat16S1_S1_Lb0ELb0ELb1ELb0ELb0EEvPT1_PT2_PT3_R18conv2d_bf16_paramsS7_S7_


I think we can use a readable name

martien-de-jong · 2026-01-16T09:49:28Z

Just a convention, 'Adding baseline tests' would label a commit adding unit tests that you expect to change.
"Adding unit tests" would then add tests that you observed were missing, containing behaviour you want to keep.
As a reviewer, I usually just skim commits of the first category, since I will see the changes in the functional commits.

martien-de-jong · 2026-01-16T09:58:26Z

llvm/lib/Target/AIE/AIE2TargetMachine.cpp

 }

 void AIE2PassConfig::addPostRewrite() {
+  if (EnableStackMinimization) {


Probably not, but checking anyway, don't we have an AIEBasePassConfig where we can add this?

martien-de-jong · 2026-01-16T10:05:09Z