[REVERTED] testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement

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

> Date: Tue, 9 Apr 2024 15:18:10 -0500
> From: Segher Boessenkool <segher@kernel.crashing.org>

> All (target-specific) new testsuite failures are just like that: bad
> testcases!

With a touch of bad assumptions by port-specific code, no
doubt.  Maybe also rtx costs including my pet peeve, the
default implementation of insn_costs (the one that doesn't
look at the destination of setters and which when you try
fixing it, pulls you down a rabbit-hole of cost-related
regressions that even Bernd S. backed away from).

> So no, no reversion.

(...)

> > That's the only test that's improved to the point of
> > affecting test-patterns.  E.g. pr93372-5.c (which references
> > pr93372-2.c) is also improved, though it retains a redundant
> > compare insn.  (PR 93372 was about regressions from the cc0
> > representation; not further improvement like here, thus it's
> > not tagged.  Though, I did not double-check whether this
> > actually *was* a regression from cc0.)
> 
> Interesting that this improved tests for you.  Huh.  Do you have an
> explanation how this happened?

Just a hunch: less combine churn (more straightforward code)
made cmpelim's job easier, same thing you wrote in order
words:

>  I suspect that as uaual it is just a
> side effect of random factors: combine is opportunistic, always does the
> first change it thinks good, not considering what this then does for
> other possible combinations; it is greedy.  It would be nice to see
> written out what happens in this example though :-)

Yes it would, but I have other things on my plate.  Besides,
it's your patch, can't rob you of the fun.

I committed the revert below, but hope to re-apply
(re-revert) it in stage 1, when as per Richard B's message
the combine improvement will reappear.

brgds, H-P

-- >8 --
From: Hans-Peter Nilsson <hp@axis.com>
Date: Wed, 10 Apr 2024 17:24:10 +0200
Subject: [PATCH] Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass
 from combine improvement"

This reverts commit 4c8b3600c4856f7915281ae3ff4d97271c83a540.
---
 gcc/testsuite/gcc.target/cris/pr93372-2.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-2.c b/gcc/testsuite/gcc.target/cris/pr93372-2.c
index 2ef6471a990b..912069c018d5 100644
--- a/gcc/testsuite/gcc.target/cris/pr93372-2.c
+++ b/gcc/testsuite/gcc.target/cris/pr93372-2.c
@@ -1,20 +1,19 @@
 /* Check that eliminable compare-instructions are eliminated. */
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
-/* { dg-final { scan-assembler-not "\tcmp|\ttest" } } */
-/* { dg-final { scan-assembler-not "\tnot" } } */
-/* { dg-final { scan-assembler-not "\tlsr" } } */
-/* We should get just one move, storing the result into *d.  */
-/* { dg-final { scan-assembler-times "\tmove" 1 } } */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
 
 int f(int a, int b, int *d)
 {
   int c = a - b;
 
-  /* We used to get a cmp.d with the original operands here. */
+  /* Whoops!  We get a cmp.d with the original operands here. */
   *d = (c == 0);
 
-  /* We used to get a suboptimal sequence, but now we get the optimal "sge"
-     (a.k.a "spl") re-using flags from the subtraction. */
+  /* Whoops!  While we don't get a test.d for the result here for cc0,
+     we get a sequence of insns: a move, a "not" and a shift of the
+     subtraction-result, where a simple "spl" would have done. */
   return c >= 0;
 }
-- 
2.30.2



brgds, H-P