This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian
- From: Tamar Christina <Tamar dot Christina at arm dot com>
- To: Christophe Lyon <christophe dot lyon at linaro dot org>, Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- Cc: gcc Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, "nickc at redhat dot com" <nickc at redhat dot com>
- Date: Fri, 6 Jul 2018 13:24:12 +0000
- Subject: RE: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian
- References: <20180619141354.GA28904@arm.com> <5B2A139C.4020409@foss.arm.com> <20180620103338.GA17888@arm.com> <5B2A5815.4050203@foss.arm.com> <CAKdteOaexEkRQ8TddRK4ZSLG7VyB4CWVF9088HQwQXU85qZxqQ@mail.gmail.com>
Hi Christoph,
> 90d62e699bce9594879be2e3016c9b36c7e064c8..703632240822e762a90657096
> > >> 4b949c783df56f3 100644
> > >> --- a/gcc/config/arm/arm.c
> > >> +++ b/gcc/config/arm/arm.c
> > >> @@ -31508,8 +31508,8 @@ arm_can_change_mode_class
> (machine_mode from, machine_mode to,
> > >> {
> > >> if (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)
> > >> + && (GET_MODE_UNIT_SIZE (from) > UNITS_PER_WORD
> > >> + || GET_MODE_UNIT_SIZE (to) > UNITS_PER_WORD)
> > >>
>
> After this commit (r262436), I have noticed regressions on armeb-none-linux-
> gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16
> FAIL: gcc.dg/vect/vect-nop-move.c execution test
> FAIL: g++.dg/torture/vshuf-v2si.C -O3 -g execution test
> FAIL: g++.dg/torture/vshuf-v4si.C -O3 -g execution test
> FAIL: g++.dg/torture/vshuf-v8hi.C -O3 -g execution test
>
> Can you have a look?
Sorry! I know you reported these before so I did explicitly test them, but it turns
out a configuration issue in our scripts was causing armeb linux builds to skip
execution tests. So the execution parts of these tests never showed up and so the
regression was clean.
I know what's wrong and will submit a patch soon.
Thanks,
Tamar
>
> > >> Does GET_MODE_UNIT_SIZE do what you want? Its documentation in
> rtl.texi says:
> > >> "Returns the size in bytes of the subunits of a datum of mode @var{m}.
> > >> This is the same as @code{GET_MODE_SIZE} except in the case of
> complex
> > >> modes. For them, the unit size is the size of the real or imaginary
> > >> part."
> > >>
> > >> Does it also do the right thing for vector modes (GET_MODE_SIZE
> (GET_MODE_INNER (mode))) ?
> > >> If so, this patch is ok, but we'll need to update the documentation to
> make it more explicit.
> > > I don't know what the documentation is trying to say here, but the key is
> the first part:
> > >
> > > "returns the size in bytes of the subunits of a datum of mode m"
> > >
> > > MODE: V4SI, GET_MODE_UNIT_SIZE: 4, GET_MODE_SIZE: 16
> > >
> > > So GET_MODE_UNIT_SIZE (m) * GET_MODE_NUNITS(m) ==
> GET_MODE_SIZE (m)
> > >
> > > or GET_MODE_UNIT_SIZE (m) == GET_MODE_SIZE (GET_MODE_INNER
> (mode)).
> > >
> > > From this the only time GET_MODE_UNIT_SIZE is equal to
> > > GET_MODE_SIZE is on non-vector modes of V1 vector modes.
> >
> > Right, this is what I thought, but the documentation is not as clear as it
> could be.
> > Your patch is ok for trunk.
> >
> > Thanks,
> > Kyrill
> >
> > > Kind Regards,
> > > Tamar
> > >
> > >> Thanks for the patch,
> > >> Kyrill
> > >>
> > >>
> > >>
> >