[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Peter Bergner --- Fixed on trunk.
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||628871.html
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 --- Comment #3 from Peter Bergner --- (In reply to Peter Bergner from comment #2) > The code change that led to this looks correct to me. Are we possibly just > folding more than we used to (a good thing), and that is changing our > numbers? What are the actual and expected counts? So looking at the differences between "before" and "after", we're seeing: test6_nor: .LFB13: .cfi_startproc - xxlor 34,34,35 li 9,0 lvx 0,0,9 addi 10,1,-16 xxpermdi 32,32,32,2 stxvd2x 32,0,10 xxpermdi 32,32,32,2 - vsububm 2,0,2 - vspltisw 0,-1 + xxlnor 34,34,35 vaddubm 2,2,0 stvx 2,0,9 blr ...so yes, we are getting more folding than before and the generated code is better, so we should update the expected counts. It seems to be the same issue in all of the tests.
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target Milestone|--- |14.0
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Peter Bergner changed: What|Removed |Added CC||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- The code change that led to this looks correct to me. Are we possibly just folding more than we used to (a good thing), and that is changing our numbers? What are the actual and expected counts? I'm sorry for repeating myself, but I really really dislike counting xxlor insns, since they're mostly used for register copies and the number of those can easily change with the phase of the moon, day of the week, etc. etc.
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- test6_nor in fold-vec-logical-ors-char.c Trying 10, 9 -> 11: 10: r127:V16QI=const_vector // (-1) 9: r125:V16QI=r126:V16QI-r124:V16QI REG_DEAD r126:V16QI REG_DEAD r124:V16QI 11: r121:V16QI=r125:V16QI+r127:V16QI REG_DEAD r127:V16QI REG_DEAD r125:V16QI REG_EQUAL r125:V16QI+const_vector Failed to match this instruction: (set (reg:V16QI 121 [ ]) (plus:V16QI (not:V16QI (reg:V16QI 124)) (reg:V16QI 126 [ *foo_4(D) ]))) Successfully matched this instruction: (set (reg:V16QI 127) (not:V16QI (reg:V16QI 124))) Successfully matched this instruction: (set (reg:V16QI 121 [ ]) (plus:V16QI (reg:V16QI 127) (reg:V16QI 126 [ *foo_4(D) ]))) allowing combination of insns 9, 10 and 11 original costs 4 + 20 + 4 = 28 replacement costs 4 + 4 = 8 deferring deletion of insn with uid = 9. modifying insn i210: r127:V16QI=~r124:V16QI REG_DEAD r124:V16QI deferring rescan insn with uid = 10. modifying insn i311: r121:V16QI=r127:V16QI+r126:V16QI REG_DEAD r126:V16QI REG_DEAD r127:V16QI deferring rescan insn with uid = 11.
