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

[Alexandre Oliva <oliva@adacore.com>]

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.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive