| Message ID | 20240405020601.C492220432@pchp3.se.axis.com |
|---|---|
| State | New |
| Headers | show |
| Series | [COMMITTED] testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement | expand |
Hi! On Fri, Apr 05, 2024 at 04:06:01AM +0200, Hans-Peter Nilsson wrote: > The xpassing change in generated code was as follows, at > r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert > to verify that this suspect was the cause). That was so > much of an improvement that I had to share it! Worth the > testsuite churn anyway. :) > > Segher, if you end up reverting r14-9692-g839bc42772ba7a (as > unfortunately seems not unlikely), then please also revert this > commit: r14-9799-g4c8b3600c4856f7915281ae3ff4d97271c83a540. I won't revert it, it fixes an actual bug. Not a regression no, but a very serious longstanding problem. We have accidentally done a limited version of a feature requested for more than 20 years now, "UNCSE". I'll do this for just combine (instead of as a separate pass, lots of issues there with pass ordering, results could be better though) in GCC 15. This really is a stage 1 thing though! Any testcase that relies on something that combine does not promise and that can not reasonably be expected to always hold is *buggy*. The combine-2-2 testcase (that I wrote myself) isn't very good, and should be replaced by something that is much more clearly a 2->2 combination, instead of 1->1 with context. All (target-specific) new testsuite failures are just like that: bad testcases! 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? 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 :-) Segher
--- pr93372-2.s.pre 2024-04-05 01:49:47.985685902 +0200 +++ pr93372-2.s.post 2024-04-05 01:42:02.296489730 +0200 @@ -5,12 +5,9 @@ .global _f .type _f, @function _f: - move.d $r10,$r9 - sub.d $r11,$r9 - cmp.d $r11,$r10 - seq $r10 - move.d $r10,[$r12] - cmpq 0,$r9 + sub.d $r11,$r10 + seq $r9 + move.d $r9,[$r12] ret sge $r10 -- >8 -- After r14-9692-g839bc42772ba7a, a sequence that actually looks optimal is now emitted, observed at r14-9788-gb7bd2ec73d66f7. This caused an XPASS for this test. While adjusting the test, better also guard it against regressions by checking that there are no redundant move insns. 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.) * gcc.target/cris/pr93372-2.c: Tweak scan-assembler checks to cover recent combine improvement. --- gcc/testsuite/gcc.target/cris/pr93372-2.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/gcc/testsuite/gcc.target/cris/pr93372-2.c b/gcc/testsuite/gcc.target/cris/pr93372-2.c index 912069c018d5..2ef6471a990b 100644 --- a/gcc/testsuite/gcc.target/cris/pr93372-2.c +++ b/gcc/testsuite/gcc.target/cris/pr93372-2.c @@ -1,19 +1,20 @@ /* Check that eliminable compare-instructions are eliminated. */ /* { dg-do compile } */ /* { dg-options "-O2" } */ -/* { dg-final { scan-assembler-not "\tcmp|\ttest" { xfail *-*-* } } } */ -/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */ -/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */ +/* { 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 } } */ int f(int a, int b, int *d) { int c = a - b; - /* Whoops! We get a cmp.d with the original operands here. */ + /* We used to get a cmp.d with the original operands here. */ *d = (c == 0); - /* 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. */ + /* We used to get a suboptimal sequence, but now we get the optimal "sge" + (a.k.a "spl") re-using flags from the subtraction. */ return c >= 0; }