aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-vectorizer.h
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2020-09-29 11:41:26 +0100
committerRichard Sandiford <richard.sandiford@arm.com>2020-09-29 11:41:26 +0100
commit95e10b8aa1066dbd5c433e613652674b0636fcd1 (patch)
tree4e1cc447f662a0cc917b4f8b29cf6b27e449bd81 /gcc/tree-vectorizer.h
parent30784833af015a9a74f5315d54f9dc08e1bbdf94 (diff)
downloadgcc-95e10b8aa1066dbd5c433e613652674b0636fcd1.zip
gcc-95e10b8aa1066dbd5c433e613652674b0636fcd1.tar.gz
gcc-95e10b8aa1066dbd5c433e613652674b0636fcd1.tar.bz2
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.
Diffstat (limited to 'gcc/tree-vectorizer.h')
0 files changed, 0 insertions, 0 deletions