RE: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's patches, Part I)

["Greta Yorsh" <Greta dot Yorsh at arm dot com>]

On 31 May 2012 19:18, Paul Brook wrote:
> > 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.

I ran a full regression test of gcc configured with cpu arm7tdmi on qemu. Is
there another ARMv4t configuration that should be tested?

> - iWMMXT has special alignment requirements.
> - Interrupt functions with special prologue/epilogue.  Both traditional
> ARM
> and Cortex-M3.

A few tests for interrupt functions are included in gcc's regression suite.
Specifically, the test gcc.target/arm/handler-align.c checks that the stack
pointer is handled correctly in prologue/epilogue of Cortex-M interrupt
handlers. I have a patch (not yet posted) to make this test more effective. 

> - -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).

For interrupt-related tests, interworking, and several other tests, I've
compared the assembly outputs before and after the patch (and caught a
couple of bugs this way).
In most cases now, the assembly outputs before and after the patch are
identical. The few differences I have seen are due to successful compiler
optimizations, where we benefit from having generated epilogues in RTL. For
example, replacing "sub sp, fp, #0" with "mov sp, fp" in epilogue. Also,
explicit write to callee-saved registers to restore them in epilgoue allows
the data flow analysis pass to deduce that registers are dead and enables
peephole optimizations that were not possible before. 

> 
> > * 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.

Thanks for pointing out additional configurations to test. I will test
-mtpcs-frame and -mtpcs-leaf-frame as you suggested and run regression tests
for iWMMXT. 

Properly testing FPA variants at this point is a lot of work, especially
considering the fact that these variants are obsolete. What minimal
configurations would be sufficient to test?

Thank you,
Greta