[all-commits] [llvm/llvm-project] 772e49: [ARM, MVE] Revise immediate VBIC/VORR to look more ...

[Simon Tatham via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 772e4931932270a82f38c83d4344c800b2f54eff
      https://github.com/llvm/llvm-project/commit/772e4931932270a82f38c83d4344c800b2f54eff
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2020-01-23 (Thu, 23 Jan 2020)

  Changed paths:
    M llvm/lib/Target/ARM/ARMInstrMVE.td
    M llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
    M llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMInstPrinter.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMInstPrinter.h
    M llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
    M llvm/unittests/Target/ARM/MachineInstrTest.cpp

  Log Message:
  -----------
  [ARM,MVE] Revise immediate VBIC/VORR to look more like NEON.

Summary:
In NEON, the immediate forms of VBIC and VORR are each represented as
a single MC instruction, which takes its immediate operand already
encoded in a NEON-friendly format: 8 data bits, plus some control bits
indicating how to expand them into a full vector.

In MVE, we represented immediate VBIC and VORR as four separate MC
instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or
24 bits. For each one, the value of the immediate operand is in the
'natural' form, i.e. the numerical value that would actually be BICed
or ORRed into each vector lane (and also the same value shown in
assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as
0xab0000, which NEON would represent as 0xab | (control bits << 8).

The MVE approach is superficially nice (it makes assembly input and
output easy, and it's also nice if you're manually constructing
immediate VBICs). But it turns out that it's better for isel if we
make the NEON and MVE instructions work the same, because the
ARMISD::VBICIMM and VORRIMM node types already encode their immediate
into the NEON format, so it's easier if we can just use it.

Also, this commit reduces the total amount of code rather than
increasing it, which is surely an indication that it really is simpler
to do it this way!

Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM

Reviewed By: dmgreen

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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


  Commit: 4321c6af28e9cc26d385fc388b8f0a74b32741c1
      https://github.com/llvm/llvm-project/commit/4321c6af28e9cc26d385fc388b8f0a74b32741c1
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2020-01-23 (Thu, 23 Jan 2020)

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td
    M clang/include/clang/Basic/arm_mve_defs.td
    M clang/include/clang/Sema/Sema.h
    M clang/lib/Sema/SemaChecking.cpp
    A clang/test/CodeGen/arm-mve-intrinsics/bitwise-imm.c
    M clang/test/Sema/arm-mve-immediates.c
    M clang/utils/TableGen/MveEmitter.cpp
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/lib/Target/ARM/ARMInstrInfo.td
    M llvm/lib/Target/ARM/ARMInstrMVE.td
    M llvm/lib/Target/ARM/ARMInstrNEON.td
    A llvm/test/CodeGen/Thumb2/mve-intrinsics/bitwise-imm.ll

  Log Message:
  -----------
  [ARM,MVE] Support immediate vbicq,vorrq,vmvnq intrinsics.

Summary:
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 (now that I've
also reworked those instructions to use the same MC operand encoding).
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`.

The predicated forms of VBIC and VORR are represented as a vector
select between the original input vector and the output of the
unpredicated operation. The main convenience of this is that it still
lets me use the existing isel lowering for VBICIMM/VORRIMM, and not
have to write another copy of the operand encoding translation code.

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.

Also adjusted the isel pattern for `vmovlb.u8`, which stopped matching
because lowering started turning its input into a VBICIMM. Now it
recognizes the VBICIMM instead.

Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard

Reviewed By: dmgreen

Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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


Compare: https://github.com/llvm/llvm-project/compare/e8fc8507dacb...4321c6af28e9