On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote: > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET) > > From: Richard Biener <rguent...@suse.de> > > > On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote: > > > > > > From: Hans-Peter Nilsson <h...@axis.com> > > > > Date: Thu, 30 Nov 2023 18:09:10 +0100 > > > > > > Richard B.: > > > > > > In the end we might need to move/duplicate the test to some > > > > > > gcc.target/* dir and restrict it to a specific tuning. > > > > > > > > I intend to post two alternative patches to get this > > > > resolved: > > > > 1: Move the tests to gcc.target/i386/scev-[3-5].c > > > > > > Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, > > > -4.c and -5.c [PR112786] > > > > > > This is the first alternative, perhaps the more appropriate one. > > > > > > Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32, > > > h8300-elf and shle-linux; xpassing, skipped and passing as > > > applicable and intended. > > > > > > Ok to commit? > > > > Digging in history reveals the testcases were added by > > Jiangning Liu <jiangning....@arm.com>, not for any > > particular bugreport but "The problem is originally from a real benchmark, > > and the test case only tries to detect the GIMPLE level changes." > > > > I'm not sure we can infer the testcase should be moved to > > gcc.target/arm/ because of that, but it does seem plausible. > > It's been so long and so many changes since these tests were > regression guards, that the original target has lost > importance. Heck, it was even xfail lp64 at one time! > According to my git dig, it's been adjusted for pass > changes, including reordering and dump output changes. But > you know that; you've been instrumental in many of those > changes. :) > > I'd say gcc.target/arm/ is the one target that's *not* > plausible, as according to Alex result differs between > subtargets. > > > I read from your messages that the testcases pass on arm*-*-*? > > Yes: they pass (currently XPASS) on arm-eabi and > arm-unknown-linux-gnueabi, default configurations. But, > scev-3 and -5 fail with for example -mcpu=cortex-r5
I see. As said, the testcases test for "cost" things, so that we "regressed" might mean we really "regressed" here. Even the x86 -m32 result is questionable. Of course whether using a single IV makes sense for all archs is unknown. Btw, if we turn the testcases into ones that are (sub-)target specific then we want to again use C code as input. I think at this point we've lost track and I'm juggling between removing the testcases or moving them to a place they succeed (with some specific -mcpu=?) Richard.
