[all-commits] [llvm/llvm-project] cf7e98: [ARM, MVE] Add intrinsics for vdupq.

Mon Feb 3 03:20:17 PST 2020

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: cf7e98e6f7805f4e2693a6dbbd12c10fe06fde70
      https://github.com/llvm/llvm-project/commit/cf7e98e6f7805f4e2693a6dbbd12c10fe06fde70
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2020-02-03 (Mon, 03 Feb 2020)

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td
    A clang/test/CodeGen/arm-mve-intrinsics/dup.c
    M llvm/lib/Target/ARM/ARMInstrMVE.td
    A llvm/test/CodeGen/Thumb2/mve-intrinsics/dup.ll

  Log Message:
  -----------
  [ARM,MVE] Add intrinsics for vdupq.

Summary:
The unpredicated case of this is trivial: the clang codegen just makes
a vector splat of the input, and LLVM isel is already prepared to
handle that. For the predicated version, I've generated a `select`
between the same vector splat and the `inactive` input parameter, and
added new Tablegen isel rules to match that pattern into a predicated
`MVE_VDUP` instruction.

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/D73356

  Commit: f8d4afc49ad21b7abc2957d15008596e49b7562b
      https://github.com/llvm/llvm-project/commit/f8d4afc49ad21b7abc2957d15008596e49b7562b
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2020-02-03 (Mon, 03 Feb 2020)

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td
    M clang/include/clang/Basic/arm_mve_defs.td
    A clang/test/CodeGen/arm-mve-intrinsics/idup.c
    M clang/test/Sema/arm-mve-immediates.c
    M clang/utils/TableGen/MveEmitter.cpp
    M llvm/include/llvm/IR/IntrinsicsARM.td
    M llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
    A llvm/test/CodeGen/Thumb2/mve-intrinsics/idup.ll

  Log Message:
  -----------
  [ARM,MVE] Add intrinsics for v[id]dupq and v[id]wdupq.

Summary:
These instructions generate a vector of consecutive elements starting
from a given base value and incrementing by 1, 2, 4 or 8. The `wdup`
versions also wrap the values back to zero when they reach a given
limit value. The instruction updates the scalar base register so that
another use of the same instruction will continue the sequence from
where the previous one left off.

At the IR level, I've represented these instructions as a family of
target-specific intrinsics with two return values (the constructed
vector and the updated base). The user-facing ACLE API provides a set
of intrinsics that throw away the written-back base and another set
that receive it as a pointer so they can update it, plus the usual
predicated versions.

Because the intrinsics return two values (as do the underlying
instructions), the isel has to be done in C++.

This is the first family of MVE intrinsics that use the `imm_1248`
immediate type in the clang Tablegen framework, so naturally, I found
I'd given it the wrong C integer type. Also added some tests of the
check that the immediate has a legal value, because this is the first
time those particular checks have been exercised.

Finally, I also had to fix a bug in MveEmitter which failed an
assertion when I nested two `seq` nodes (the inner one used to extract
the two values from the pair returned by the IR intrinsic, and the
outer one put on by the predication multiclass).

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/D73357

  Commit: 961530fdc9f7e97ce8945788bb25e09787c49811
      https://github.com/llvm/llvm-project/commit/961530fdc9f7e97ce8945788bb25e09787c49811
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2020-02-03 (Mon, 03 Feb 2020)

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td
    M clang/include/clang/Basic/arm_mve_defs.td
    M clang/lib/CodeGen/CGBuiltin.cpp
    M clang/test/CodeGen/arm-mve-intrinsics/admin.c
    A clang/test/CodeGen/arm-mve-intrinsics/reinterpret.c
    M llvm/include/llvm/IR/IntrinsicsARM.td
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/lib/Target/ARM/ARMISelLowering.h
    M llvm/lib/Target/ARM/ARMInstrMVE.td
    M llvm/test/CodeGen/Thumb2/mve-be.ll

  Log Message:
  -----------
  [ARM,MVE] Fix vreinterpretq in big-endian mode.

Summary:
In big-endian MVE, the simple vector load/store instructions (i.e.
both contiguous and non-widening) don't all store the bytes of a
register to memory in the same order: it matters whether you did a
VSTRB.8, VSTRH.16 or VSTRW.32. Put another way, the in-register
formats of different vector types relate to each other in a different
way from the in-memory formats.

So, if you want to 'bitcast' or 'reinterpret' one vector type as
another, you have to carefully specify which you mean: did you want to
reinterpret the //register// format of one type as that of the other,
or the //memory// format?

The ACLE `vreinterpretq` intrinsics are specified to reinterpret the
register format. But I had implemented them as LLVM IR bitcast, which
is specified for all types as a reinterpretation of the memory format.
So a `vreinterpretq` intrinsic, applied to values already in registers,
would code-generate incorrectly if compiled big-endian: instead of
emitting no code, it would emit a `vrev`.

To fix this, I've introduced a new IR intrinsic to perform a
register-format reinterpretation: `@llvm.arm.mve.vreinterpretq`. It's
implemented by a trivial isel pattern that expects the input in an
MQPR register, and just returns it unchanged.

In the clang codegen, I only emit this new intrinsic where it's
actually needed: I prefer a bitcast wherever it will have the right
effect, because LLVM understands bitcasts better. So we still generate
bitcasts in little-endian mode, and even in big-endian when you're
casting between two vector types with the same lane size.

For testing, I've moved all the codegen tests of vreinterpretq out
into their own file, so that they can have a different set of RUN
lines to check both big- and little-endian.

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/D73786

Compare: https://github.com/llvm/llvm-project/compare/bdbdf7482255...961530fdc9f7