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

[Richard Biener <rguenther@suse.de>]

On Thu, 30 Nov 2023, Alexandre Oliva wrote:

> On Nov 29, 2023, Hans-Peter Nilsson <hp@axis.com> wrote:
> 
> >> 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.
> 
> My arm-eabi testing then targeted tms570 (big-endian cortex-r5).
> 
> I borrowed the ilp32 vs lp64 line from an internal patch by Eric that
> we've had in gcc-11 and gcc-12, when I hit this fail while transitioning
> the first and then the second of our 32-bit targets to gcc-13.
> 
> Eric, would you happen to recall where the notion that lp64 was a good
> heuristic for these tests?
> 
> > 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 haven't even seen scev-4.c fail, I only got reports that it did.
> 
> I'm not even claiming it fails, I'm only claiming it has been observed
> to fail on some ilp32 targets, and nobody seems to have a good sense of
> when it's supposed to pass or fail, so my reasoning was that making it
> an expected fail is less alarming than seeing actual failures on some
> targets.  It was known to be imprecise, but to be an improvement over
> getting a FAIL for some reasonably common targets when there was no
> reason to expect it to actually pass, or even to have ever passed.
> 
> > So, ilp32 is IMO a really bad approximation for the elusive
> > property.
> 
> Yeah.  Maybe we should just drop the ilp32, so that it's an unsurprising
> fail on any targets?
> 
> > Would you please consider changing those "ilp32" to a
> > specific set of targets where these tests failed?
> 
> I'd normally have aimed for that, but the challenge is that arm-eabi is
> not uniform in the results for this test, and there doesn't seem to be
> much support or knowledge to delineate on which target variants it's
> meant to pass or not.  The test expects the transformation to take
> place, as if it ought to, but there's no strong reason to expect that it
> should.  There's nothing wrong if it doesn't.  Going about trying to
> match the expectations to the current results may be useful, but
> investigating the reasons why we get the current results for each target
> is beyond my available resources for a set of tests that used to *seem*
> to pass uniformly only because of a bug in the test pattern.
> 
> I don't see much value in these tests as they are, TBH.

As I said the tests are really testing IVOPTs costing which is
target specific.  Maybe we should move them to gcc.target/$X
and figure what target they were originally intended to cover ...

Richard.