https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546
--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> --- Created attachment 43764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43764&action=edit Alternate patch for PR80546 Mike created the vsx_mov<mode>_* patterns, so I asked him why he disparaged the GPR moves. He said that reload (not LRA?) was attempting to use the GPR moves for vector types and that was causing some horrible code. I can understand that, but I don't understand why we should disparage them for the integer types (DImode and TImode), since they normally live in GPRs to begin with. With that in mind, I created the attached patch which seems to create better code for the ptr4 test case than current trunk without changing the other functions. Looking at the difference between the unpatched and patched bool3-p8.s files, I see: --- bool3-p8-old.s 2018-03-26 21:15:38.293963450 -0500 +++ bool3-p8-new.s 2018-03-26 21:16:27.514854332 -0500 @@ -134,13 +134,8 @@ # gpr reg 10 # 0 "" 2 #NO_APP - mtvsrd 0,10 - mtvsrd 1,11 - xxpermdi 12,0,1,0 - xxlnor 0,12,12 - mfvsrd 10,0 - xxpermdi 0,0,0,3 - mfvsrd 11,0 + not 10,10 + not 11,11 #APP # 76 "/home/bergner/gcc/gcc-fsf-mainline-pr84878/gcc/testsuite/gcc.target/powerpc/bool3.h" 1 # gpr reg 10 Mike, anyone, does this look reasonable? I'll mention that the costs for BASE_REGS/GENERAL_REGS for r122 are much more reasonable compared to what Jakub was seeing on Comment 3 with the unpatched compiler. My bootstrap/regtesting of this patch is still running. Mike, do we have a test case where this matters?
