[all-commits] [llvm/llvm-project] 902e84: [ARM, MVE] Add intrinsics for 'administrative' vect...

[Simon Tatham via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 902e84556a51c70d95088aaa059ab9c494ab3516
      https://github.com/llvm/llvm-project/commit/902e84556a51c70d95088aaa059ab9c494ab3516
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2019-11-15 (Fri, 15 Nov 2019)

  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/admin.c
    M clang/utils/TableGen/MveEmitter.cpp

  Log Message:
  -----------
  [ARM,MVE] Add intrinsics for 'administrative' vector operations.

This batch of intrinsics includes lots of things that move vector data
around or change its type without really affecting its value very
much. It includes the `vreinterpretq` family (cast one vector type to
another); `vuninitializedq` (create a vector of a given type with
don't-care contents); and `vcreateq` (make a 128-bit vector out of two
`uint64_t` halves).

These are all implemented using completely standard IR that's already
tested in existing LLVM unit tests, so I've just written a clang test
to check the IR is correct, and left it at that.

I've also added some richer infrastructure to the MveEmitter Tablegen
backend, to make it specify the exact integer type of integer
arguments passed to IR construction functions, and wrap those
arguments in a `static_cast` in the autogenerated C++. That was
necessary to prevent an overloading ambiguity when passing the integer
literal `0` to `IRBuilder::CreateInsertElement`, because otherwise, it
could mean either a null pointer `llvm::Value *` or a zero `uint64_t`.

Reviewers: ostannard, MarkMurrayARM, dmgreen

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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


  Commit: 9e37892773c0954a15f84b011223da1e707ab3bf
      https://github.com/llvm/llvm-project/commit/9e37892773c0954a15f84b011223da1e707ab3bf
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2019-11-15 (Fri, 15 Nov 2019)

  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/get-set-lane.c
    M clang/test/CodeGen/arm-mve-intrinsics/load-store.c
    M clang/test/CodeGen/arm-mve-intrinsics/scalar-shifts.c
    M clang/test/CodeGen/arm-mve-intrinsics/scatter-gather.c
    M clang/test/CodeGen/arm-mve-intrinsics/vadc.c
    M clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
    M clang/test/CodeGen/arm-mve-intrinsics/vcvt.c
    M clang/test/CodeGen/arm-mve-intrinsics/vld24.c
    M clang/test/CodeGen/arm-mve-intrinsics/vldr.c
    M clang/test/CodeGen/arm-mve-intrinsics/vminvq.c
    M clang/test/Sema/arm-mve-immediates.c
    M clang/utils/TableGen/MveEmitter.cpp

  Log Message:
  -----------
  [ARM,MVE] Add intrinsics for vector get/set lane.

This adds the `vgetq_lane` and `vsetq_lane` families, to copy between
a scalar and a specified lane of a vector.

One of the new `vgetq_lane` intrinsics returns a `float16_t`, which
causes a compile error if `%clang_cc1` doesn't get the option
`-fallow-half-arguments-and-returns`. The driver passes that option to
cc1 already, but I've had to edit all the explicit cc1 command lines
in the existing MVE intrinsics tests.

A couple of fixes are included for the code I wrote up front in
MveEmitter to support lane-index immediates (and which nothing has
tested until now): the type was wrong (`uint32_t` instead of `int`)
and the range was off by one.

I've also added a method of bypassing the default promotion to `i32`
that is done by the MveEmitter code generation: it's sensible to
promote short scalars like `i16` to `i32` if they're going to be
passed to custom IR intrinsics representing a machine instruction
operating on GPRs, but not if they're going to be passed to standard
IR operations like `insertelement` which expect the exact type.

Reviewers: ostannard, MarkMurrayARM, dmgreen

Reviewed By: dmgreen

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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


Compare: https://github.com/llvm/llvm-project/compare/87054ec07bd5...9e37892773c0