[all-commits] [llvm/llvm-project] 9e9be9: [AArch64][SME] Disable remat of VL-dependent ops w...

[sdesmalen-arm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9e9be99c972e125c640a30000731547beb006084
      https://github.com/llvm/llvm-project/commit/9e9be99c972e125c640a30000731547beb006084
  Author: Sander de Smalen <sander.desmalen at arm.com>
  Date:   2023-09-01 (Fri, 01 Sep 2023)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.h
    M llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.h
    A llvm/test/CodeGen/AArch64/sme-disable-rematerialize-with-streaming-mode-changes.ll

  Log Message:
  -----------
  [AArch64][SME] Disable remat of VL-dependent ops when function changes streaming mode.

This is a way to prevent the register allocator from inserting instructions
which behave differently for different runtime vector-lengths, inside a
call-sequence which changes the streaming-SVE mode before/after the call.

I've considered using BUNDLEs in Machine IR, but found that using this is
not possible for a few reasons:
* Most passes don't look inside BUNDLEs, but some passes would need to
  look inside these call-sequence bundles, for example the PrologEpilog
  pass (to remove the CALLSEQSTART/END), a PostRA pass to remove COPY
  instructions, or the AArch64PseudoExpand pass.
* Within the streaming-mode-changing call sequence, one of the instructions
  is a CALLSEQEND. The corresponding CALLSEQBEGIN (AArch64::ADJCALLSTACKUP)
  is outside this sequence. This means we'd end up with a BUNDLE that has
  [SMSTART, COPY, BL, ADJCALLSTACKUP, COPY, SMSTOP]. The MachineVerifier
  doesn't accept this, and we also can't move the CALLSEQSTART into the
  call sequence.

Maybe in the future we could model this differently by modelling
the runtime vector-length as a value that's used by certain operations
(similar to e.g. NCZV flags) and clobbered by SMSTART/MMSTOP, such that the
register allocator can consider these as actual dependences and avoid
rematerialization. For now we just want to address the immediate problem.

Reviewed By: paulwalker-arm, aemerson

Differential Revision: https://reviews.llvm.org/D159193