[all-commits] [llvm/llvm-project] 38f016: [ARM MVE] Remove accidental 64-bit vst2/vld2 intri...

Wed Nov 6 01:02:03 PST 2019

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

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td

  Log Message:
  -----------
  [ARM MVE] Remove accidental 64-bit vst2/vld2 intrinsics.

ACLE defines no such intrinsic as vst2q_u64, and the MVE instruction
set has no corresponding instruction. But I had accidentally added
them to the fledgling <arm_mve.h> anyway, and if you used them, you'd
get a compiler crash.

Reviewers: dmgreen

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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

  Commit: 26bc7cb05edd6bea4b9a1593baf0fbe9e45f54e4
      https://github.com/llvm/llvm-project/commit/26bc7cb05edd6bea4b9a1593baf0fbe9e45f54e4
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2019-11-06 (Wed, 06 Nov 2019)

  Changed paths:
    M clang/utils/TableGen/MveEmitter.cpp

  Log Message:
  -----------
  [clang,MveEmitter] Fix sign/zero extension in range limits.

In the code that generates Sema range checks on constant arguments, I
had a piece of code that checks the bounds specified in the Tablegen
intrinsic description against the range of the integer type being
tested. If the bounds are large enough to permit any value of the
integer type, you can omit the compile-time range check. (This case is
expected to come up in some of the bitwise operation intrinsics.)

But somehow I got my signed/unsigned check backwards (asking for the
signed min/max of an unsigned type and vice versa), and also made a
sign extension error in which a signed negative value gets
zero-extended. Now rewritten more sensibly, and it should get its
first sensible test from the next batch of intrinsics I'm planning to
add in D69791.

Reviewers: dmgreen

Subscribers: cfe-commits

Tags: #clang

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

  Commit: f0c6890f32c0d5ee7f3973181eb83fcb0a50dc1a
      https://github.com/llvm/llvm-project/commit/f0c6890f32c0d5ee7f3973181eb83fcb0a50dc1a
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2019-11-06 (Wed, 06 Nov 2019)

  Changed paths:
    M clang/include/clang/Basic/arm_mve.td
    M clang/include/clang/Basic/arm_mve_defs.td
    M clang/utils/TableGen/MveEmitter.cpp

  Log Message:
  -----------
  [ARM,MVE] Integer-type nitpicks in MVE intrinsics.

A few integer types in the ACLE definitions of MVE intrinsics are
given as 'int' or 'unsigned' instead of <stdint.h> fixed-size types
like uint32_t. Usually these are the ones where the size isn't that
important, such as immediate offsets in loads (which have a range
limited by the instruction encoding) or the carry flag in vadcq which
can only be 0 or 1 anyway.

With this change, <arm_mve.h> follows that exact type naming, so that
the function prototypes look identical to the ones in ACLE, instead of
replacing int and unsigned with int32_t and uint32_t.

Reviewers: dmgreen

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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

  Commit: 6c3fee47a6492b472be2d48cee0a85773f160df0
      https://github.com/llvm/llvm-project/commit/6c3fee47a6492b472be2d48cee0a85773f160df0
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2019-11-06 (Wed, 06 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/scatter-gather.c
    A 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/ARMInstrMVE.td
    A llvm/test/CodeGen/Thumb2/mve-intrinsics/scatter-gather.ll

  Log Message:
  -----------
  [ARM,MVE] Add intrinsics for gather/scatter load/stores.

This patch adds two new families of intrinsics, both of which are
memory accesses taking a vector of locations to load from / store to.

The vldrq_gather_base / vstrq_scatter_base intrinsics take a vector of
base addresses, and an immediate offset to be added consistently to
each one. vldrq_gather_offset / vstrq_scatter_offset take a scalar
base address, and a vector of offsets to add to it. The
'shifted_offset' variants also multiply each offset by the element
size type, so that the vector is effectively of array indices.

At the IR level, these operations are represented by a single set of
four IR intrinsics: {gather,scatter} × {base,offset}. The other
details (signed/unsigned, shift, and memory element size as opposed to
vector element size) are all specified by IR intrinsic polymorphism
and immediate operands, because that made the selection job easier
than making a huge family of similarly named intrinsics.

I considered using the standard IR representations such as
llvm.masked.gather, but they're not a good fit. In order to use
llvm.masked.gather to represent a gather_offset load with element size
smaller than a pointer, you'd have to expand the <8 x i16> vector of
offsets into an <8 x i16*> vector of pointers, which would be split up
during legalization, so you'd spend most of your time undoing the mess
it had made. Also, ISel support for llvm.masked.gather would be easy
enough in a trivial way (you can expand it into a gather-base load
with a zero immediate offset), but instruction-selecting lots of
fiddly idioms back into all the _other_ MVE load instructions would be
much more work. So I think dedicated IR intrinsics are the more
sensible approach, at least for the moment.

On the clang tablegen side, I've added two new features to the
Tablegen source accepted by MveEmitter: a 'CopyKind' type node for
defining a type that varies with the parameter type (it lets you ask
for an unsigned integer type of the same width as the parameter), and
an 'unsignedflag' value node for passing an immediate IR operand which
is 0 for a signed integer type or 1 for an unsigned one. That lets me
write each kind of intrinsic just once and get all its subtypes and
immediate arguments generated automatically.

Also I've tweaked the handling of pointer-typed values in the code
generation part of MveEmitter: they're generated as Address rather
than Value (i.e. including an alignment) so that they can be given to
the ordinary IR load and store operations, but I'd omitted the code to
convert them back to Value when they're going to be used as an
argument to an IR intrinsic.

On the MC side, I've enhanced MVEVectorVTInfo so that it can tell you
not only the full assembly-language suffix for a given vector type
(like 's32' or 'u16') but also the numeric-only one used by store
instructions (just '32' or '16').

Reviewers: dmgreen

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

Tags: #clang, #llvm

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

Compare: https://github.com/llvm/llvm-project/compare/7ea4c6fa5121...6c3fee47a649