[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Alan Modra changed: What|Removed |Added Priority|P1 |P3 --- Comment #21 from Alan Modra --- The patch I have to fix this bug is too intrusive for gcc-9, and I haven't tried to find some other hack (likely would be dangerous too). Marking as a P3.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #20 from Segher Boessenkool --- I currently get (on BE; the testcase forces -mcpu=power8): std 3,-16(1) addi 9,1,-12 lxsiwzx 32,0,9 #APP # 10 "vsx-simode2.c" 1 xxlor 32,32,32 # v, v constraints # 0 "" 2 #NO_APP mfvsrwz 3,32 blr so yes this test _should_ fail, we do the wrong thing. NO_REGS is chosen for this reg class, no vector class is considered.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #19 from Bill Schmidt --- Looking at gcc-testresults, looks like we currently fail the test with FAIL: gcc.target/powerpc/vsx-simode2.c scan-assembler mtvsrwz for P7 BE, P8 LE, and P9 LE using current trunk. Alan and Segher, do we know more about this yet?
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #18 from Richard Biener --- Status update?
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Richard Biener changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #17 from Richard Biener --- *** Bug 89292 has been marked as a duplicate of this bug. ***
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Alan Modra changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-03/msg01299.ht ||ml CC|amodra at gmail dot com| --- Comment #16 from Alan Modra --- Patch posted.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- What is the current status of this PR?
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #14 from Segher Boessenkool --- Cool results so far! +FAIL: gcc.target/powerpc/p9-dimode1.c scan-assembler-not \\mmtvsrd\\M p9_plus_1: .LFB1: .cfi_startproc - vspltisw 0,1 - vupklsw 0,0 + li 9,1 + mtvsrd 0,9 The new code is actually cheaper on p9. The test is wrong?
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Alan Modra changed: What|Removed |Added Attachment #45760|0 |1 is obsolete|| --- Comment #13 from Alan Modra --- Created attachment 45808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45808=edit Current set of patches
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #12 from Alan Modra --- Author: amodra Date: Sun Feb 24 02:01:05 2019 New Revision: 269174 URL: https://gcc.gnu.org/viewcvs?rev=269174=gcc=rev Log: [RS6000] Fix _ and tf_ splitters This patch fixes a bug that can result in "insn does not satisfy its constraints" if these splitters fire due to not getting ctr for the jump insn. Since the jump insn can have any of r,m,d,wi,c,l as the decremented count output, it's not sufficient to check for gpc_reg_operand (which matches VSX regs for example). Seen after correcting register_move_cost when the cost of gpr <-> vsx is much lower. Since this is a prerequisite to fixing PR89271, I'm mentioning that PR in the ChangeLog. The tf_ split had a further bug in that it wouldn't match if the count output was m,d,wi, or l. PR target/89271 * config/rs6000/rs6000.md (_ split): Check for an int output reg on add insn. (tf_ split): Likewise. Match predicates with insn. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #11 from Vladimir Makarov --- (In reply to Alan Modra from comment #5) > Created attachment 45760 [details] > Current set of patches > > It turns out there is a lot more than just wrong register_move_cost. This > patchset does fix the PR without introducing too many regressions, but it is > a work in progress. > > I have some questions about union register classes: > 1) What should register_move_cost return for a union class like > GEN_OR_VSX_REGS and some other class? Worst case, best case, or doesn't it > matter? > 2) What should preferred_reload_class return for union classes? > Looking at other ports doesn't shed much light.. IRA uses practically the same algorithm as the old RA. Only instead of pseudos, pseudo ranges (allocnos) are used. It is hard to describe the algorithm briefly. It has a few drawbacks. Roughly speaking it does not take into account that, when we calculate the costs, different pseudo operands should be on the same insn alternative. Choosing the classes implicitly affects on a final choice of insn alternative. For some time I worked on different approach which is based on choosing insn alternatives first and then calculating the costs. The code for this is currently on branch ira-select. As for register move costs inside an union class, for better RA results I think we should not take costs of moves between different subclasses into account. So it should be a minimal costs of moves only inside subclasses. For example, if we have GENERAL_FLOATING_REGS class the cost for moves inside the class (from GENERAL_FLOATING_REGS to GENERAL_FLOATING_REGS) should be not cost of move from GENERAL to FLOAT class but minimal cost of move only inside GENERAL class and only inside FLOAT class. Analogously, for moves between two different classes (when one or both classes are an union classes), we should use minimal cost of moves from subclasses of the two classes. The most common case when the algorithm chooses union classes is one when we use a pseudo to implement memory-memory move. For example, moving memory through general or float registers has the same cost. If we use maximal cost for moves between regs of GENERAL_FLOATING_REGS, the algorithm decreases the number of registers which can be used for such moves by using only general or only float regs. That is how I see the right approach but I never benchmarked different approaches, for example, on SPEC. So the approach I propose here has not been checked on practice.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #10 from Alan Modra --- > NON_SPECIAL_REGS removal The gcc docs say of register classes: "You should define a class for the union of two classes whenever some instruction allows both classes." So this would seem to be going in the wrong direction. We have quite a few insns that allow gprs in one alternative and vsx/fpr/altivec in another. I don't know whether the docs are up to date for ira/lra but my analysis of the ppc-round3.c failure (see the notes in the patches I attached) after fixing integer register move cost suggests that register allocation is better with union classes available. Note that x86 does have union classes.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #9 from Segher Boessenkool --- Erm. No new ICEs, I mean. Various tests expect different generated code then you get with that. Some of it is an improvement.
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #8 from Segher Boessenkool --- I currently have the two previous patches in my stack, and I see no regressions (on powerpc64-linux -m32/-m64).
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #7 from Segher Boessenkool --- Created attachment 45768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45768=edit NON_SPECIAL_REGS removal
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #6 from Segher Boessenkool --- Created attachment 45767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45767=edit reg_move_cost patch
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #5 from Alan Modra --- Created attachment 45760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45760=edit Current set of patches It turns out there is a lot more than just wrong register_move_cost. This patchset does fix the PR without introducing too many regressions, but it is a work in progress. I have some questions about union register classes: 1) What should register_move_cost return for a union class like GEN_OR_VSX_REGS and some other class? Worst case, best case, or doesn't it matter? 2) What should preferred_reload_class return for union classes? Looking at other ports doesn't shed much light..
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #4 from Alan Modra --- Author: amodra Date: Sun Feb 17 03:01:41 2019 New Revision: 268968 URL: https://gcc.gnu.org/viewcvs?rev=268968=gcc=rev Log: [RS6000] Fix _ and tf_ splitters This patch fixes a bug that can result in "insn does not satisfy its constraints" if these splitters fire due to not getting ctr for the jump insn. Since the jump insn can have any of r,m,d,wi,c,l as the decremented count output, it's not sufficient to check for gpc_reg_operand (which matches VSX regs for example). Seen after correcting register_move_cost when the cost of gpr <-> vsx is much lower. Since this is a prerequisite to fixing PR89271, I'm mentioning that PR in the ChangeLog. The tf_ split had a further bug in that it wouldn't match if the count output was m,d,wi, or l. PR target/89271 * config/rs6000/rs6000.md (_ split): Check for an int output reg on add insn. (tf_ split): Likewise. Match predicates with insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
