> Date: Tue, 9 Apr 2024 15:18:10 -0500
> From: Segher Boessenkool <seg...@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 <h...@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
