This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's patches, Part I)
- From: "Greta Yorsh" <Greta dot Yorsh at arm dot com>
- To: "'Paul Brook'" <paul at codesourcery dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>, <joseph at codesourcery dot com>, "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>, <sameera dot deshpande at gmail dot com>, "Ramana Radhakrishnan" <Ramana dot Radhakrishnan at arm dot com>, <nickc at redhat dot com>
- Date: Mon, 18 Jun 2012 17:28:27 +0100
- Subject: RE: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's patches, Part I)
- References: <000001cd3f33$5b5c25a0$121470e0$@Yorsh@arm.com> <201205311918.14279.paul@codesourcery.com>
Paul,
I did additional testing of the patches, as you suggested.
For iwmmxt, no regression on qemu (using -cpu pxa270) for arm-none-eabi
taget configured --with-cpu iwmmxt --with-float soft --with-arch iwmmxt
--with-abi iwmmxt --disable-multilib. There is already a test for mmx stack
alignment in gcc.target/arm/mmx-1.c. I have also tested a few other options
(including -mtcps-frame and -mtpcs-leaf-frame) on several examples and
haven't found any problems with the patches (at least, not yet :)
Separately, I submitted a couple of testsuite patches related to RTL
epilogue:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01175.html
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01176.html
FPA support is in the process of being removed from ARM backend trunk:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00825.html
I hope it addresses your concerns.
Following Richard's comments, I removed FPA support from RTL epilogue
patches, rebased patches to trunk, and fixed some formatting problems. I'll
go ahead and apply individual patches that have already been approved.
Thank you,
Greta
> -----Original Message-----
> From: Paul Brook [mailto:paul@codesourcery.com]
> Sent: 31 May 2012 19:18
> To: Greta Yorsh
> Cc: GCC Patches; joseph@codesourcery.com; Richard Earnshaw;
> sameera.deshpande@gmail.com; Ramana Radhakrishnan; nickc@redhat.com
> Subject: Re: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's
> patches, Part I)
>
> > Testing:
> > * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp
> and
> > tested in three configuration: -marm (default), -mthumb, -mapcs-
> frame. No
> > regression on qemu.
> > * Crossbuild for target arm-none-eabi thumb2 with cpu cortex-m3. No
> > regression on qemu.
> > * Crossbuild for target arm-none-eabi thumb1 with cpu arm7tdmi and
> > arm1136jf-s. No regression on qemu.
> > * Crossbuild for target arm-linux-gnueabi with cpu cortex-a9 with
> eglibc
> > and used this compiler to build AEL linux kernel. It boots
> successfully. *
> > Bootstrap the compiler on cortex-a8 successfully for
> > --languages=c,c++,fortran and used this compiler to build gdb. No
> > regression with check-gcc and check-gdb.
>
> What other testing have you done? Thate's a good number of
> combinations not
> covered by your above list. In particular:
> - Coverage of old cores looks pretty thin. In particular ARMv4t has
> different
> interworking requirements.
> - iWMMXT has special alignment requirements.
> - Interrupt functions with special prologue/epilogue. Both traditional
> ARM
> and Cortex-M3.
> - -mtpcs-frame and -mtpcs-leaf-frame
>
> Some of these options are orthogonal.
>
> As you've proved with -mapcs-frame it's near impossible to get these
> right
> without actually testing them. I'm not saying you have to do a full
> testrun
> in every combination, but it's worth testing a representative selection
> of
> functions (large and small frame, leaf or not, with and without frame
> pointer,
> uses alloca, etc). Also worth explicitly clobbering a selection (both
> odd and
> even numbers) of callee saved registers to make sure we get that right.
> Any
> difference in the output should be manually verified (ideally the
> assembly
> output would be identical).
>
> > * The patches have not been explicitly tested with any FPA variants
> (which
> > are deprecated in 4.7 and expected to become obsolete in 4.8).
>
> I'm not keen on breaking these without actually removing them.
>
> Paul