[all-commits] [llvm/llvm-project] 9052fb: [AArch64][SME] Support split ZPR and PPR area allo...

[Benjamin Maxwell via All-commits]

  Branch: refs/heads/users/MacDue/split_pprs
  Home:   https://github.com/llvm/llvm-project
  Commit: 9052fbd556b6eeb961b6a8b8536be5c26ac8d79d
      https://github.com/llvm/llvm-project/commit/9052fbd556b6eeb961b6a8b8536be5c26ac8d79d
  Author: Benjamin Maxwell <benjamin.maxwell at arm.com>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
    M llvm/lib/Target/AArch64/AArch64FrameLowering.h
    M llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.h
    A llvm/test/CodeGen/AArch64/framelayout-split-sve.mir
    M llvm/test/CodeGen/AArch64/spill-fill-zpr-predicates.mir
    A llvm/test/CodeGen/AArch64/split-sve-stack-frame-layout.ll
    M llvm/test/CodeGen/AArch64/stack-hazard.ll
    M llvm/test/CodeGen/AArch64/sve-stack-frame-layout.ll

  Log Message:
  -----------
  [AArch64][SME] Support split ZPR and PPR area allocation

For a while we have supported the `-aarch64-stack-hazard-size=<size>`
option, which adds "hazard padding" between GPRs and FPR/ZPRs. However,
there is currently a hole in this mitigation as PPR and FPR/ZPR accesses
to the same area also cause streaming memory hazards (this is noted by
`-pass-remarks-analysis=sme -aarch64-stack-hazard-remark-size=<val>`),
and the current stack layout places PPRs and ZPRs within the same area.

Which looks like:

------------------------------------  Higher address
| callee-saved gpr registers        |
|---------------------------------- |
| lr,fp  (a.k.a. "frame record")    |
|-----------------------------------| <- fp(=x29)
|   <hazard padding>                |
|-----------------------------------|
| callee-saved fp/simd/SVE regs     |
|-----------------------------------|
|        SVE stack objects          |
|-----------------------------------|
| local variables of fixed size     |
|   <FPR>                           |
|   <hazard padding>                |
|   <GPR>                           |
------------------------------------| <- sp
                                    | Lower address

With this patch the stack (and hazard padding) is rearranged so that
hazard padding is placed between the PPRs and ZPRs rather than within
the (fixed size) callee-save region. Which looks something like this:

------------------------------------  Higher address
| callee-saved gpr registers        |
|---------------------------------- |
| lr,fp  (a.k.a. "frame record")    |
|-----------------------------------| <- fp(=x29)
|        callee-saved PPRs          |
|        PPR stack objects          | (These are SVE predicates)
|-----------------------------------|
|   <hazard padding>                |
|-----------------------------------|
|       callee-saved ZPR regs       | (These are SVE vectors)
|        ZPR stack objects          | Note: FPRs are promoted to ZPRs
|-----------------------------------|
| local variables of fixed size     |
|   <FPR>                           |
|   <hazard padding>                |
|   <GPR>                           |
------------------------------------| <- sp
                                    | Lower address

This layout is only enabled if:

 * SplitSVEObjects are enabled (`-aarch64-split-sve-objects`)
   - (This may be enabled by default in a later patch)
 * Streaming memory hazards are present
   - (`-aarch64-stack-hazard-size=<val>` != 0)
 * PPRs and FPRs/ZPRs are on the stack
 * There's no stack realignment or variable-sized objects
   - This is left as a TODO for now

Additionally, any FPR callee-saves that are present will be promoted to
ZPRs. This is to prevent stack hazards between FPRs and GRPs in the
fixed size callee-save area (which would otherwise require more hazard
padding, or moving the FPR callee-saves).

This layout should resolve the hole in the hazard padding mitigation,
and is not intended change codegen for non-SME code.



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