> From: Rainer Orth <r...@cebitec.uni-bielefeld.de> > Date: Tue, 28 Nov 2023 16:13:35 +0100
> Richard Biener <rguent...@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
