[PATCH] D65884: [ARM] MVE Tail Predication

Sam Parker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 7 08:21:12 PDT 2019


samparker created this revision.
samparker added reviewers: dmgreen, SjoerdMeijer, simon_tatham, olista01, samtebbs.
Herald added subscribers: zzheng, kristof.beyls, javed.absar, mgorny.

The MVE and LOB extensions of Armv8.1m can be combined to enable 'tail predication' which removes the need for a scalar remainder loop after vectorization. Lane predication is performed implicitly via a system register. The effects of predication is described in Section B5 <https://reviews.llvm.org/B5>.6.3 of the Armv8.1-m Arch Reference Manual, the key points being:

- For vector operations that perform reduction across the vector and produce a scalar result, whether the value is accumulated or not.
- For non-load instructions, the predicate flags determine if the destination register byte is updated with the new value or if the previous value is preserved.
- For vector store instructions, whether the store occurs or not.
- For vector load instructions, whether the value that is loaded or whether zeros are written to that element of the destination register.

This patch implements a pass that takes a hardware loop, containing masked vector instructions, and converts it something that resembles an MVE tail predicated loop. Currently, if we had code generation, we'd generate a loop in which the VCTP would generate the predicate and VPST would then setup the value of VPR.PO. The loads and stores would be placed in VPT blocks so this is not tail predication, but normal VPT predication with the predicate based upon a element counting induction variable. Further work needs to be done to finally produce a true tail predicated loop.

      

Because only the loads and stores are predicated, in both the LLVM IR and MIR level, we will restrict support to only lane-wise operations (no horizontal reductions). Predicated reductions don't make sense in LLVM IR, the vectorizer won't allow the predication to happen in their presence, and we will perform a final check on MIR during loop finalisation.

      

Another restriction, specific to MVE, is that all the vector instructions need operate on the same number of elements. This is because predication is performed at the byte level and this is set on entry to the loop, or by the VCTP instead.

      

Intrinsics for VCTP variants, as well as one for its conversion, has been added to generate the predicate. The conversion is required because the architected predicate, both from a software and hardware perspective, is a 16-bit scalar, whereas we need an i1 vector in IR.


https://reviews.llvm.org/D65884

Files:
  include/llvm/IR/IntrinsicsARM.td
  lib/Target/ARM/ARM.h
  lib/Target/ARM/ARMTargetMachine.cpp
  lib/Target/ARM/CMakeLists.txt
  lib/Target/ARM/Thumb2TailPredication.cpp
  test/CodeGen/Thumb2/LowOverheadLoops/basic-tail-pred.ll
  test/CodeGen/Thumb2/LowOverheadLoops/tail-pred-narrow.ll
  test/CodeGen/Thumb2/LowOverheadLoops/tail-pred-pattern-fail.ll
  test/CodeGen/Thumb2/LowOverheadLoops/tail-pred-widen.ll
  test/CodeGen/Thumb2/LowOverheadLoops/vector-unroll.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D65884.213894.patch
Type: text/x-patch
Size: 92726 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190807/af7d8485/attachment.bin>


More information about the llvm-commits mailing list