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

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

> From: Alexandre Oliva <oliva@adacore.com>
> Date: Thu, 30 Nov 2023 01:41:55 -0300

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

'k, I interpret that as that ilp32 being mostly a copy-paste
of unclear origin, and that there weren't actually any
observation of more than two ilp32 targets failing (counting
ia32 and one or more non-default armeb).

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

That situation suggests to me to *skip* it for arm*-*-*.
For other targets, skip or xfail as needed after a quick
look.  Or as per below.

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

Richard B. seems to have been the last person doing
significant work on those tests (rewriting scev-[3-5].c to
gimple tests for ivopts, commit r7-6026-ga23e48df4514c4), so
I value his suggestion per below particularly valuable:

> > 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
2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
   only on h8300-*-* and ia32.

If you can help with e.g. reviewing, thanks in advance.

I opened PR112786 to get an ID for the issue.

brgds, H-P