On 25/02/14 09:56, Kyrill Tkachov wrote: > 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. >
Please fix the backslashes so that they all line up correctly. OK both with that tweak. R. > > change-mode-class.patch > > > 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))) >
