Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson <hp@axis.com>]

> From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
> Date: Tue, 28 Nov 2023 16:13:35 +0100

> Richard Biener <rguenther@suse.de> writes:
> 
> > On Sun, 19 Nov 2023, Jeff Law wrote:
> >
> >> 
> >> 
> >> On 11/19/23 00:30, Alexandre Oliva wrote:
> >> > 
> >> > I've recently patched scev-3.c and scev-5.c because it only passed by
> >> > accident on ia32.  It also fails on some (but not all) arm-eabi
> >> > variants.  It seems hard to characterize the conditions in which the
> >> > optimization is supposed to pass, but expecting them to fail on ilp32
> >> > targets, though probably a little excessive and possibly noisy, is not
> >> > quite as alarming as getting a fail in test reports, so I propose
> >> > changing the xfail marker from ia32 to ilp32.
> >> > 
> >> > I'm also proposing to add a similar marker to scev-4.c.  Though it
> >> > doesn't appear to be failing for me, I've got reports that suggest it
> >> > still does for others, and it certainly did for us as well.
> >> > 
> >> > Regstrapped on x86_64-linux-gnu, also tested on arm-eabi with default
> >> > cpu on trunk, and with tms570 on gcc-13.  Ok to install?
> >> > 
> >> > 
> >> > for  gcc/testsuite/ChangeLog
> >> > 
> >> >  * gcc.dg/tree-ssa/scev-3.c: xfail on all ilp32 targets,
> >> >  though some of these do pass.
> >> >  * gcc.dg/tree-ssa/scev-4.c: Likewise.
> >> >  * gcc.dg/tree-ssa/scev-5.c: Likewise.
> >> OK.  Though hopefully someone will figure out what properties actually cause
> >> the differences so that we can do the right thing without the noisy XPASS at
> >> some point.
> >
> > The tests all test IVOPTs induction variable selecting results
> > (assuming every target would come to the "obvious" conclusion),
> > so it's probably not only target but also sub-target (aka -mtune)
> > sensitive ...
> >
> > In the end we might need to move/duplicate the test to some
> > gcc.target/* dir and restrict it to a specific tuning.
> 
> FWIW, since Alexandre's patch all three tests XPASS on 32-bit
> Solaris/SPARC:
> 
> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1
> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1
> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1

It XPASSes on the ilp32 targets I've tried - except "ia32"
(as in i686-elf) and h8300-elf.  Notably XPASSing targets
includes a *default* configuration of arm-eabi, which in
part contradicts your observation above.  I see it even
XPASSes in H.J.'s x86_64-pc-linux-gnu -mx32 results.  Right,
that's not ia32, but it's as ilp32ish as ia32 and can be
expected to share most "interesting" properties with ia32.
Example report at
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801862.html.

Alex, can you share the presumably plural set of targets
where you found gcc.dg/tree-ssa/scev-[3-5].c to fail before
your patch, besides "ia32"?

I see them XPASS for:
m68k-unknown-linux-gnu
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801839.html)
pru-unknown-elf
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/801732.html)

and from my own testing, at r14-5608-g69741355e6dbcf:
cris-elf, c6x-elf, epiphany-elf, ft32-elf,
hppa-unknown-linux-gnu, lm32-elf, microblaze-linux,
m32r-elf, arm-eabi.

So, ilp32 is IMO a really bad approximation for the elusive
property.

Would you please consider changing those "ilp32" to a
specific set of targets where these tests failed?

I'd prefer not to complicate those expressions by adding the
right spelling of "ilp32 except { list }".

brgds, H-P