| Message ID | 530C68E0.90700@arm.com |
|---|---|
| State | New |
| Headers | show |
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.tkachov@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))) >
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)))
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.tkachov@arm.com> PR target/55426 * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Allow 128 to 64-bit conversions.