[PATCH] D72934: [ARM,MVE] Support immediate vbicq,vorrq,vmvnq intrinsics.

Simon Tatham via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 17 09:17:17 PST 2020


simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls.
Herald added projects: clang, LLVM.

Immediate vmvnq is code-generated as a simple vector constant in IR,
and left to the backend to recognize that it can be created with an
MVE VMVN instruction. The predicated version is represented as a
select between the input and the same constant, and I've added a
Tablegen isel rule to turn that into a predicated VMVN. (That should
be better than the previous VMVN + VPSEL: it's the same number of
instructions but now it can fold into an adjacent VPT block.)

The unpredicated forms of VBIC and VORR are done by enabling the same
isel lowering as for NEON, recognizing appropriate immediates and
rewriting them as ARMISD::VBICIMM / ARMISD::VORRIMM SDNodes, which I
then instruction-select into the right MVE instructions (but in custom
C++, because of the awkward MC representation). In order to do that, I
had to promote the Tablegen SDNode instance `NEONvorrImm` to a general
`ARMvorrImm` available in MVE as well, and similarly for `NEONvbicImm`.

For the predicated forms of VBIC and VORR, I've just invented IR
intrinsics. I considered trying to match a call to the existing
predicated VBIC intrinsic where one argument was a vector splat, but
it looked like needing a lot more code than it would give benefit.

This intrinsic family is the first to use the `imm_simd` system I put
into the MveEmitter tablegen backend. So, naturally, it showed up a
bug or two (emitting bogus range checks and the like). Fixed those,
and added a full set of tests for the permissible immediates in the
existing Sema test.

Finally, the new isel support for immediate VBIC has caused changes in
a few existing MVE codegen tests, because `vbic.i16 q0,#0xff00` has
now taken over from `vmovlb.u8 q0,q0` as LLVM's preferred way to clear
the top byte of each 16-bit lane. I think the changes are benign.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72934

Files:
  clang/include/clang/Basic/arm_mve.td
  clang/include/clang/Basic/arm_mve_defs.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/arm-mve-intrinsics/bitwise-imm.c
  clang/test/Sema/arm-mve-immediates.c
  clang/utils/TableGen/MveEmitter.cpp
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMInstrInfo.td
  llvm/lib/Target/ARM/ARMInstrMVE.td
  llvm/lib/Target/ARM/ARMInstrNEON.td
  llvm/test/CodeGen/Thumb2/mve-gather-ptrs.ll
  llvm/test/CodeGen/Thumb2/mve-intrinsics/bitwise-imm.ll
  llvm/test/CodeGen/Thumb2/mve-masked-load.ll
  llvm/test/CodeGen/Thumb2/mve-sext.ll
  llvm/test/CodeGen/Thumb2/mve-shuffleext.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D72934.238803.patch
Type: text/x-patch
Size: 59069 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200117/5e08a8d6/attachment-0001.bin>


More information about the cfe-commits mailing list