Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01253.html
Thanks,
Kyrill
On 10/11/15 17:32, Kyrill Tkachov wrote:
Hi all,
This ICE in this PR occurs when we're trying to split unaligned_loaddi into two
SImode unaligned loads.
The problem is in the addressing mode. When reload was picking the addressing
mode we accepted an offset of
-256 because the mode in the pattern is advertised as DImode and that was
accepted by the legitimate address
hooks because they thought it was a NEON load (DImode is in
VALID_NEON_DREG_MODE). However, the splitter wants
to generate two normal SImode unaligned loads using that address, for which
-256 is not valid, so we ICE
in gen_lowpart.
The only way unaligned_loaddi could be generated was through the
gen_movmem_ldrd_strd expansion that implements
a memmove using LDRD and STRD sequences. If the memmove source is not aligned
we can't use LDRDs so the code
generates unaligned_loaddi patterns and expects them to be split into two
normal loads after reload. Similarly
for unaligned store destinations.
This patch just explicitly generates the two unaligned SImode loads or stores
when appropriate inside
gen_movmem_ldrd_strd. This makes the unaligned_loaddi and unaligned_storedi
patterns unused, so we can remove them.
This patch fixes the ICe in gcc.target/aarch64/advsimd-intrinsics/vldX.c seen
with
-mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee
so no new testcase is added.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok for trunk?
Thanks,
Kyrill
2015-11-10 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/68149
* config/arm/arm.md (unaligned_loaddi): Delete.
(unaligned_storedi): Likewise.
* config/arm/arm.c (gen_movmem_ldrd_strd): Don't generate
unaligned DImode memory ops. Instead perform two back-to-back
unalgined SImode ops.
