arm: Add new vector mode macros
authorRichard Sandiford <richard.sandiford@arm.com>
Tue, 29 Sep 2020 10:41:26 +0000 (11:41 +0100)
committerRichard Sandiford <richard.sandiford@arm.com>
Tue, 29 Sep 2020 10:41:26 +0000 (11:41 +0100)
commit95e10b8aa1066dbd5c433e613652674b0636fcd1
tree4e1cc447f662a0cc917b4f8b29cf6b27e449bd81
parent30784833af015a9a74f5315d54f9dc08e1bbdf94
arm: Add new vector mode macros

The AArch32 port now has three vector extensions: iwMMXt, Neon
and MVE.  We already have some named expanders that are shared
by all three, and soon we'll need more.

One way of handling this would be to use define_mode_iterators
that specify the condition for each mode.  For example,

  (V16QI "TARGET_NEON || TARGET_HAVE_MVE")
  (V8QI "TARGET_NEON || TARGET_REALLY_IWMXXT")
  ...
  (V2SF "TARGET_NEON && flag_unsafe_math_optimizations")

etc.  However, we'll need several mode iterators, and it would
be repetitive to specify the mode condition every time.

This patch therefore introduces per-mode macros that say whether
we can perform general arithmetic on the mode.  Initially there are
two sets of macros:

ARM_HAVE_NEON_<MODE>_ARITH
  true if Neon can handle general arithmetic on <MODE>

ARM_HAVE_<MODE>_ARITH
  true if any vector extension can handle general arithmetic on <MODE>

The macro definitions themselves are undeniably ugly, but hopefully
they're justified by the simplifications they allow.

The patch converts the addition patterns to use this scheme.

Previously there were three copies of the V8HF and V4HF addition
patterns for Neon:

(1) *add<VDQ:mode>3_neon, which provided plus:VnHF even without
    TARGET_NEON_FP16INST.  This was probably harmless since all the
    named patterns had an appropriate guard, but it is possible that
    something could have tried to generate the plus directly, such as
    by using a REG_EQUAL note to generate a new pattern.

(2) addv8hf3_neon and addv4hf3, which had the correct
    TARGET_NEON_FP16INST target condition, but unnecessarily required
    flag_unsafe_math_optimizations.  Unlike VnSF operations, VnHF
    operations do not force flush to zero.

(3) add<VH:mode>3_fp16, which provided plus:VnHF with the
    correct conditions (TARGET_NEON_FP16INST, with no
    flag_unsafe_math_optimizations test).

The patch in essence renames add<VH:mode>3_fp16 to *add<VH:mode>3_neon
(part of *add<VDQ:mode>3_neon) and removes the other two patterns.

gcc/
* config/arm/arm.h (ARM_HAVE_NEON_V8QI_ARITH, ARM_HAVE_NEON_V4HI_ARITH)
(ARM_HAVE_NEON_V2SI_ARITH, ARM_HAVE_NEON_V16QI_ARITH): New macros.
(ARM_HAVE_NEON_V8HI_ARITH, ARM_HAVE_NEON_V4SI_ARITH): Likewise.
(ARM_HAVE_NEON_V2DI_ARITH, ARM_HAVE_NEON_V4HF_ARITH): Likewise.
(ARM_HAVE_NEON_V8HF_ARITH, ARM_HAVE_NEON_V2SF_ARITH): Likewise.
(ARM_HAVE_NEON_V4SF_ARITH, ARM_HAVE_V8QI_ARITH, ARM_HAVE_V4HI_ARITH)
(ARM_HAVE_V2SI_ARITH, ARM_HAVE_V16QI_ARITH, ARM_HAVE_V8HI_ARITH)
(ARM_HAVE_V4SI_ARITH, ARM_HAVE_V2DI_ARITH, ARM_HAVE_V4HF_ARITH)
(ARM_HAVE_V2SF_ARITH, ARM_HAVE_V8HF_ARITH, ARM_HAVE_V4SF_ARITH):
Likewise.
* config/arm/iterators.md (VNIM, VNINOTM): Delete.
* config/arm/vec-common.md (add<VNIM:mode>3, addv8hf3)
(add<VNINOTM:mode>3): Replace with...
(add<VDQ:mode>3): ...this new expander.
* config/arm/neon.md (*add<VDQ:mode>3_neon): Use the new
ARM_HAVE_NEON_<MODE>_ARITH macros as the C condition.
(addv8hf3_neon, addv4hf3, add<VFH:mode>3_fp16): Delete in
favor of the above.
(neon_vadd<VH:mode>): Use gen_add<mode>3 instead of
gen_add<mode>3_fp16.

gcc/testsuite/
* gcc.target/arm/armv8_2-fp16-arith-2.c: Expect FP16 vectorization
even without -ffast-math.
gcc/config/arm/arm.h
gcc/config/arm/iterators.md
gcc/config/arm/neon.md
gcc/config/arm/vec-common.md
gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-2.c