[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #13 from Martin Liška --- commit r9-8357-g85c08558c66dd8e2000a4ad282ca03368028fce3 Author: Xionghu Luo Date: Mon Mar 9 20:25:20 2020 -0500 Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036. Tested pass on P9/P8/P7. (gcc-8 is not needed as the test doesn't exists.) P9LE generated instruction is not worse than P8LE. mtvsrdd;xxlnot;stxv vs. not;not;std;std. It can have longer latency, but latency via memory is not so critical, and this does save decode and other resources. It's hard to choose which is best. Update the test case to fix failures. gcc/testsuite/ChangeLog: 2020-03-10 Luo Xiong Hu backport from master. PR testsuite/94036 2019-12-02 Luo Xiong Hu PR testsuite/92398 * gcc.target/powerpc/pr72804.c: Split the store function to... * gcc.target/powerpc/pr92398.h: ... this one. New. * gcc.target/powerpc/pr92398.p9+.c: New. * gcc.target/powerpc/pr92398.p9-.c: New. * lib/target-supports.exp (check_effective_target_p8): New. (check_effective_target_p9+): New.
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Li Jia He changed: What|Removed |Added Status|NEW |RESOLVED CC||helijia at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from Li Jia He --- fixed on trunk together with r278918. On behave of Xiong Hu to close the issue since his account couldn't.
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-09 Ever confirmed|0 |1 --- Comment #11 from Bill Schmidt --- Confirmed. ;-) Is this ready to close?
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 --- Comment #10 from luoxhu at gcc dot gnu.org --- Author: luoxhu Revision: 278890 Modified property: svn:log Modified: svn:log at Wed Dec 4 08:50:33 2019 -- --- svn:log (original) +++ svn:log Wed Dec 4 08:50:33 2019 @@ -10,7 +10,7 @@ 2019-12-02 Luo Xiong Hu - testsuite/pr92398 + PR testsuite/92398 * gcc.target/powerpc/pr72804.c: Split the store function to... * gcc.target/powerpc/pr92398.h: ... this one. New. * gcc.target/powerpc/pr92398.p9+.c: New.
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #9 from Xiong Hu XS Luo ---
(In reply to seurer from comment #8)
> The changes in r278890 fix the earlier problems but introduce new ones:
>
> failures in r278889 (not seen in r278890):
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std 2
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not xxpermdi
>
> new failures in r278890:
>
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times \\mnot\\M 2
> FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not \\mlxvd2x\\M
>
> saw this on both power 8 (BE) and power 9 (LE).
Spaces are strictly required in dg, when I copied my patch to svn repo and run
"svn patch", there is conflicts with latest code in pr72804.c, the typo happens
when copy the line manually, will commit it as obvious:
diff --git a/gcc/testsuite/gcc.target/powerpc/pr72804.c
b/gcc/testsuite/gcc.target/powerpc/pr72804.c
index d424bccd5c3..38dff549210 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr72804.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr72804.c
@@ -1,6 +1,6 @@
/* { dg-do compile { target { lp64 } } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
-/* { dg-options "-O2 -mvsx"} */
+/* { dg-options "-O2 -mvsx" } */
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 --- Comment #8 from seurer at gcc dot gnu.org --- The changes in r278890 fix the earlier problems but introduce new ones: failures in r278889 (not seen in r278890): FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std 2 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not xxpermdi new failures in r278890: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times \\mnot\\M 2 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not \\mlxvd2x\\M saw this on both power 8 (BE) and power 9 (LE).
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 --- Comment #7 from Xiong Hu XS Luo --- Starting broken revision on Power8BE is r265398: commit 171920e88fed13ed26336ca884123eff37176c36 (HEAD, refs/bisect/bad) Author: segher Date: Mon Oct 22 20:23:39 2018 + combine: Do not combine moves from hard registers On most targets every function starts with moves from the parameter passing (hard) registers into pseudos. Similarly, after every call there is a move from the return register into a pseudo. These moves usually combine with later instructions (leaving pretty much the same instruction, just with a hard reg instead of a pseudo).
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #6 from Xiong Hu XS Luo ---
Power9 genrates different code than Power8LE is because of reg cost in sched1,
r120 from P9 of instruction 8 is a memory instruction while r120 of P8 of
instruction 13 is not, which will cause different register cost value in
function ira-cost.c:record_operand_costs(), the 2000 is P9's r120 BASE_REGS
cost, it is 0 for P8:
p op_costs[1][0]
$453 = {mem_cost = 4000, cost = {2000}}
sched1, For Power9:
P9 r120 costs: BASE_REGS:2000 GENERAL_REGS:2000 FLOAT_REGS:0 ALTIVEC_REGS:0
VSX_REGS:0 GEN_OR_FLOAT_REGS:12000 GEN_OR_VSX_REGS:12000 MEM:8000
;; basic block 2, loop depth 0
;; pred: ENTRY
5: NOTE_INSN_BASIC_BLOCK 2
11: r121:DI=%3:DI
REG_DEAD %3:DI
2: NOTE_INSN_DELETED
12: r122:TI=%4:TI
REG_DEAD %4:TI
3: NOTE_INSN_DELETED
4: NOTE_INSN_FUNCTION_BEG
7: r120:TI=~r122:TI
REG_DEAD r122:TI
8: [r121:DI]=r120:TI
REG_DEAD r121:DI
REG_DEAD r120:TI
;; succ: EXIT
sched1, For Power8LE:
r120 costs: BASE_REGS:0 GENERAL_REGS:0 FLOAT_REGS:0 ALTIVEC_REGS:0 VSX_REGS:0
GEN_OR_FLOAT_REGS:16000 GEN_OR_VSX_REGS:16000 MEM:5000
1: NOTE_INSN_DELETED
5: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_DELETED
3: NOTE_INSN_DELETED
4: NOTE_INSN_FUNCTION_BEG
12: r122:TI=%4:TI
REG_DEAD %4:TI
11: r121:DI=%3:DI
REG_DEAD %3:DI
7: r120:TI=~r122:TI
REG_DEAD r122:TI
13: r123:TI=r120:TI<-<0x40
REG_DEAD r120:TI
14: [r121:DI]=r123:TI<-<0x40
REG_DEAD r123:TI
REG_DEAD r121:DI
15: NOTE_INSN_DELETED
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 --- Comment #5 from seurer at gcc dot gnu.org --- The assembler mismatches on power 7 and power 9 date way, way back at least into early 2019. The short span where the test case failed to work at all threw me off. Sorry about that!
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #4 from Peter Bergner --- (In reply to Xiong Hu XS Luo from comment #2) > Sorry that I mistook to change the case pr72804.c: this case has no > relationship with the parameter -fno-inline-functions --param > max-inline-insns-single-O2=200. This test appears in category of "New tests > that FAIL (6 tests):". Correct, I don't think -fno-inline-functions --param max-inline-insns-single-O2=200 should have ever been added to pr72804.c. The correct thing would be to remove those options from the test case. However, I don't see how those options could be causing any change in generated assembly because there are no inlining opportunities, so how could that revision be causing the reported error? Bill, are you sure on that revision? > Peter added this case pr72804.c in r251153 of Aug 17, 2017 to generate > better code for -mvsx-timode. But it restrict the condition to > !BYTES_BIG_ENDIAN and !TARGET_P9_VECTOR: I added this test to test for poor code generation on POWER7 (and POWER8). Looking at the POWER9 output, that code looks good to me. Maybe we didn't generate that back when I added the test case? The POWER8 (BE) code does look worse to me than what we expect. Bill, can you reconfirm what revision broke pr72804.c?
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #3 from Xiong Hu XS Luo ---
Power8 BE generates:
L.bar:
.LFB1:
.cfi_startproc
mtvsrd 0,4
mtvsrd 1,5
xxpermdi 12,0,1,0
xxlnor 0,12,12
stxvd2x 0,0,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE1:
and source code is below for all:
void
bar (__int128_t *dst, __int128_t src)
{
*dst = ~src;
}
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Xiong Hu XS Luo changed: What|Removed |Added CC||luoxhu at cn dot ibm.com --- Comment #2 from Xiong Hu XS Luo --- Sorry that I mistook to change the case pr72804.c: this case has no relationship with the parameter -fno-inline-functions --param max-inline-insns-single-O2=200. This test appears in category of "New tests that FAIL (6 tests):". Checked the test result history: For Power9, it is failed since r268152 of Jan 22, 2019. https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02232.html. For Power 7, it starts to fail since r267319 of Dec 21, 2018. https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02500.html Peter added this case pr72804.c in r251153 of Aug 17, 2017 to generate better code for -mvsx-timode. But it restrict the condition to !BYTES_BIG_ENDIAN and !TARGET_P9_VECTOR: +;; Peepholes to catch loads and stores for TImode if TImode landed in +;; GPR registers on a little endian system. +(define_peephole2 + [(set (match_operand:VSX_TI 0 "int_reg_operand") + (rotate:VSX_TI (match_operand:VSX_TI 1 "memory_operand") + (const_int 64))) + (set (match_operand:VSX_TI 2 "int_reg_operand") + (rotate:VSX_TI (match_dup 0) + (const_int 64)))] + "!BYTES_BIG_ENDIAN && TARGET_VSX && TARGET_VSX_TIMODE && !TARGET_P9_VECTOR + && (rtx_equal_p (operands[0], operands[2]) + || peep2_reg_dead_p (2, operands[0]))" + [(set (match_dup 2) (match_dup 1))]) I am not sure these failures are leaved for won't fix or need update the vsx.md to generate better code? On Power9, the expected code is: 0020 : 20: f8 20 84 7c not r4,r4 24: f8 28 a5 7c not r5,r5 28: 00 00 83 f8 std r4,0(r3) 2c: 08 00 a3 f8 std r5,8(r3) 30: 20 00 80 4e blr But actual code is: 0020 : 20: 66 23 05 7c mtvsrdd vs0,r5,r4 24: 10 05 00 f0 xxlnor vs0,vs0,vs0 28: 05 00 03 f4 stxvvs0,0(r3) 2c: 20 00 80 4e blr
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 seurer at gcc dot gnu.org changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- r277904 looks like it fixes this problem but introduces (or allows it to get to) others: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not lxvd2x FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x These assembler instruction count tests are touchy and it looks like the above only happens on power 7 (BE). > FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 > FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std 2 And these only happen on power 9 (LE).
[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
