Hi all,
A while back I sent a patch to fix this PR
(http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00652.html) by generalising the
neon_vld1_dupv2di splitter. There is an alternative safer approach at this
stage, which is to relax CANNOT_CHANGE_MODE_CLASS to allow conversions from 128
to 64-bit modes. In that case the layout in the d-registers happens to be valid
in big-endian, so we don't end up generating subregs after reg allocation.
This regression appears on 4.8 as well as trunk.
Built and bootstrapped trunk and 4.8 on arm-none-linux-gnueabihf.
Ok for those branches?
Thanks,
Kyrill
2014-02-25 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/55426
* config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Allow 128 to 64-bit
conversions.diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index bed056e..df30f77 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1257,9 +1257,13 @@ enum reg_class
VFPv2.
In big-endian mode, modes greater than word size (i.e. DFmode) are stored in
VFP registers in little-endian order. We can't describe that accurately to
- GCC, so avoid taking subregs of such values. */
+ GCC, so avoid taking subregs of such values.
+ The only exception is going from a 128-bit to a 64-bit type. In that case
+ the data layout happens to be consistent for big-endian, so we explicitly allow
+ that case. */
#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
- (TARGET_VFP && TARGET_BIG_END \
+ (TARGET_VFP && TARGET_BIG_END \
+ && !(GET_MODE_SIZE (FROM) == 16 && GET_MODE_SIZE (TO) == 8) \
&& (GET_MODE_SIZE (FROM) > UNITS_PER_WORD \
|| GET_MODE_SIZE (TO) > UNITS_PER_WORD) \
&& reg_classes_intersect_p (VFP_REGS, (CLASS)))
