aboutsummaryrefslogtreecommitdiff
path: root/gcc/value-range.h
diff options
context:
space:
mode:
authorKyrylo Tkachov <kyrylo.tkachov@arm.com>2023-04-24 09:28:35 +0100
committerKyrylo Tkachov <kyrylo.tkachov@arm.com>2023-04-24 09:28:35 +0100
commit6ec565d8755afe1c187cda69fb8e478e669cfd02 (patch)
treea12071cd03cd6f7ee7d6aeab492cc198126340f4 /gcc/value-range.h
parent60bf26a412a9ec2b467c04fac1dfacef2ef09c6d (diff)
downloadgcc-6ec565d8755afe1c187cda69fb8e478e669cfd02.zip
gcc-6ec565d8755afe1c187cda69fb8e478e669cfd02.tar.gz
gcc-6ec565d8755afe1c187cda69fb8e478e669cfd02.tar.bz2
aarch64: Add pattern to match zero-extending scalar result of ADDLV
The vaddlv_u8 and vaddlv_u16 intrinsics produce a widened scalar result (uint16_t and uint32_t). The ADDLV instructions themselves zero the rest of the V register, which gives us a free zero-extension to 32 and 64 bits, similar to how it works on the GP reg side. Because we don't model that zero-extension in the machine description this can cause GCC to move the results of these instructions to the GP regs just to do a (superfluous) zero-extension. This patch just adds a pattern to catch these cases. For the testcases we can now generate no zero-extends or GP<->FP reg moves, whereas before we generated stuff like: foo_8_32: uaddlv h0, v0.8b umov w1, v0.h[0] // FP<->GP move with zero-extension! str w1, [x0] ret Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ChangeLog: * config/aarch64/aarch64-simd.md (*aarch64_<su>addlv<VDQV_L:mode>_ze<GPI:mode>): New pattern. gcc/testsuite/ChangeLog: * gcc.target/aarch64/simd/addlv_zext.c: New test.
Diffstat (limited to 'gcc/value-range.h')
0 files changed, 0 insertions, 0 deletions