* [RS6000] Fix 65576 regression @ 2015-04-02 5:22 Alan Modra 2015-04-02 17:03 ` David Edelsohn 2015-04-02 23:41 ` Michael Meissner 0 siblings, 2 replies; 7+ messages in thread From: Alan Modra @ 2015-04-02 5:22 UTC (permalink / raw) To: gcc-patches; +Cc: David Edelsohn, Michael Meissner This cures an unrecognizable insn ICE by modifying a predicate of extenddftf2_internal (the only place this predicate is used) to ensure that rtl optimization passes do not substitute 0.0 for a register with known 0.0 value, except when VSX is enabled. ie. Don't undo the necessary register move emitted by the extenddftf2_fprs expander. Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux and powerpc-linux. OK to apply? PR target/65576 PR target/65240 * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude 0.0 constant unless TARGET_VSX. Index: gcc/config/rs6000/predicates.md =================================================================== --- gcc/config/rs6000/predicates.md (revision 221805) +++ gcc/config/rs6000/predicates.md (working copy) @@ -964,7 +964,8 @@ ;; Return 1 if the operand is CONST_DOUBLE 0, register or memory operand. (define_predicate "zero_reg_mem_operand" - (ior (match_operand 0 "zero_fp_constant") + (ior (and (match_test "TARGET_VSX") + (match_operand 0 "zero_fp_constant")) (match_operand 0 "reg_or_mem_operand"))) ;; Return 1 if the operand is a CONST_INT and it is the element for 64-bit -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-02 5:22 [RS6000] Fix 65576 regression Alan Modra @ 2015-04-02 17:03 ` David Edelsohn 2015-04-02 23:19 ` Alan Modra 2015-04-02 23:41 ` Michael Meissner 1 sibling, 1 reply; 7+ messages in thread From: David Edelsohn @ 2015-04-02 17:03 UTC (permalink / raw) To: GCC Patches, Michael Meissner, Alan Modra On Thu, Apr 2, 2015 at 1:22 AM, Alan Modra <amodra@gmail.com> wrote: > This cures an unrecognizable insn ICE by modifying a predicate of > extenddftf2_internal (the only place this predicate is used) to ensure > that rtl optimization passes do not substitute 0.0 for a register with > known 0.0 value, except when VSX is enabled. ie. Don't undo the > necessary register move emitted by the extenddftf2_fprs expander. > Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux > and powerpc-linux. OK to apply? > > PR target/65576 > PR target/65240 > * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude > 0.0 constant unless TARGET_VSX. This change seems to disable the final alternative in the extenddftf2_internal pattern. - David ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-02 17:03 ` David Edelsohn @ 2015-04-02 23:19 ` Alan Modra 0 siblings, 0 replies; 7+ messages in thread From: Alan Modra @ 2015-04-02 23:19 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC Patches, Michael Meissner On Thu, Apr 02, 2015 at 01:03:19PM -0400, David Edelsohn wrote: > On Thu, Apr 2, 2015 at 1:22 AM, Alan Modra <amodra@gmail.com> wrote: > > This cures an unrecognizable insn ICE by modifying a predicate of > > extenddftf2_internal (the only place this predicate is used) to ensure > > that rtl optimization passes do not substitute 0.0 for a register with > > known 0.0 value, except when VSX is enabled. ie. Don't undo the > > necessary register move emitted by the extenddftf2_fprs expander. > > Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux > > and powerpc-linux. OK to apply? > > > > PR target/65576 > > PR target/65240 > > * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude > > 0.0 constant unless TARGET_VSX. > > This change seems to disable the final alternative in the > extenddftf2_internal pattern. It looks to me like it was already disabled, by r96390. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-02 5:22 [RS6000] Fix 65576 regression Alan Modra 2015-04-02 17:03 ` David Edelsohn @ 2015-04-02 23:41 ` Michael Meissner 2015-04-03 0:03 ` David Edelsohn 1 sibling, 1 reply; 7+ messages in thread From: Michael Meissner @ 2015-04-02 23:41 UTC (permalink / raw) To: gcc-patches, David Edelsohn, Michael Meissner On Thu, Apr 02, 2015 at 03:52:35PM +1030, Alan Modra wrote: > This cures an unrecognizable insn ICE by modifying a predicate of > extenddftf2_internal (the only place this predicate is used) to ensure > that rtl optimization passes do not substitute 0.0 for a register with > known 0.0 value, except when VSX is enabled. ie. Don't undo the > necessary register move emitted by the extenddftf2_fprs expander. > Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux > and powerpc-linux. OK to apply? > > PR target/65576 > PR target/65240 > * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude > 0.0 constant unless TARGET_VSX. > > Index: gcc/config/rs6000/predicates.md > =================================================================== > --- gcc/config/rs6000/predicates.md (revision 221805) > +++ gcc/config/rs6000/predicates.md (working copy) > @@ -964,7 +964,8 @@ > > ;; Return 1 if the operand is CONST_DOUBLE 0, register or memory operand. > (define_predicate "zero_reg_mem_operand" > - (ior (match_operand 0 "zero_fp_constant") > + (ior (and (match_test "TARGET_VSX") > + (match_operand 0 "zero_fp_constant")) > (match_operand 0 "reg_or_mem_operand"))) > > ;; Return 1 if the operand is a CONST_INT and it is the element for 64-bit > I definately prefer Alan's patch over mine. In looking at extenddftf2_internal, I believe you are correct David, in that final alternative will never match because 0.0 will not be valid (pre-VSX 0.0 won't be allowed as operand2, VSX 0.0 will not match "n" constraint). For the VSX case, the "n" should be either "j" or "E". If you are doing a double->long double conversion, and it happens to pick GPRs for some reason, the GPR side will do a load/move of 0.0 instead of using li to load 0 on pre-VSX systems. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-02 23:41 ` Michael Meissner @ 2015-04-03 0:03 ` David Edelsohn 2015-04-03 12:51 ` Alan Modra 0 siblings, 1 reply; 7+ messages in thread From: David Edelsohn @ 2015-04-03 0:03 UTC (permalink / raw) To: Michael Meissner, GCC Patches, Michael Meissner, Alan Modra On Thu, Apr 2, 2015 at 7:41 PM, Michael Meissner <meissner@linux.vnet.ibm.com> wrote: > On Thu, Apr 02, 2015 at 03:52:35PM +1030, Alan Modra wrote: >> This cures an unrecognizable insn ICE by modifying a predicate of >> extenddftf2_internal (the only place this predicate is used) to ensure >> that rtl optimization passes do not substitute 0.0 for a register with >> known 0.0 value, except when VSX is enabled. ie. Don't undo the >> necessary register move emitted by the extenddftf2_fprs expander. >> Bootstrapped and regression tested powerpc64le-linux, powerpc64-linux >> and powerpc-linux. OK to apply? >> >> PR target/65576 >> PR target/65240 >> * config/rs6000/predicates.md (zero_reg_mem_operand): Exclude >> 0.0 constant unless TARGET_VSX. >> >> Index: gcc/config/rs6000/predicates.md >> =================================================================== >> --- gcc/config/rs6000/predicates.md (revision 221805) >> +++ gcc/config/rs6000/predicates.md (working copy) >> @@ -964,7 +964,8 @@ >> >> ;; Return 1 if the operand is CONST_DOUBLE 0, register or memory operand. >> (define_predicate "zero_reg_mem_operand" >> - (ior (match_operand 0 "zero_fp_constant") >> + (ior (and (match_test "TARGET_VSX") >> + (match_operand 0 "zero_fp_constant")) >> (match_operand 0 "reg_or_mem_operand"))) >> >> ;; Return 1 if the operand is a CONST_INT and it is the element for 64-bit >> > > I definately prefer Alan's patch over mine. > > In looking at extenddftf2_internal, I believe you are correct David, in that > final alternative will never match because 0.0 will not be valid (pre-VSX 0.0 > won't be allowed as operand2, VSX 0.0 will not match "n" constraint). For the > VSX case, the "n" should be either "j" or "E". > > If you are doing a double->long double conversion, and it happens to pick GPRs > for some reason, the GPR side will do a load/move of 0.0 instead of using li to > load 0 on pre-VSX systems. If the final alternative cannot occur, it should be removed as well. Alan, would you please test that change also? Thanks, David ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-03 0:03 ` David Edelsohn @ 2015-04-03 12:51 ` Alan Modra 2015-04-03 13:35 ` David Edelsohn 0 siblings, 1 reply; 7+ messages in thread From: Alan Modra @ 2015-04-03 12:51 UTC (permalink / raw) To: David Edelsohn; +Cc: Michael Meissner, GCC Patches, Michael Meissner On Thu, Apr 02, 2015 at 08:02:57PM -0400, David Edelsohn wrote: > If the final alternative cannot occur, it should be removed as well. > Alan, would you please test that change also? Tested powerpc64-linux and powerpc-linux no regressions. * config/rs6000/rs6000.md (extenddftf2_internal): Remove last alternative. Index: gcc/config/rs6000/rs6000.md =================================================================== --- gcc/config/rs6000/rs6000.md (revision 221805) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -8369,9 +8369,9 @@ }) (define_insn_and_split "*extenddftf2_internal" - [(set (match_operand:TF 0 "nonimmediate_operand" "=m,Y,ws,d,&d,r") - (float_extend:TF (match_operand:DF 1 "input_operand" "d,r,md,md,md,rm"))) - (use (match_operand:DF 2 "zero_reg_mem_operand" "d,r,j,m,d,n"))] + [(set (match_operand:TF 0 "nonimmediate_operand" "=m,Y,ws,d,&d") + (float_extend:TF (match_operand:DF 1 "input_operand" "d,r,md,md,md"))) + (use (match_operand:DF 2 "zero_reg_mem_operand" "d,r,j,m,d"))] "!TARGET_IEEEQUAD && TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT && TARGET_LONG_DOUBLE_128" -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RS6000] Fix 65576 regression 2015-04-03 12:51 ` Alan Modra @ 2015-04-03 13:35 ` David Edelsohn 0 siblings, 0 replies; 7+ messages in thread From: David Edelsohn @ 2015-04-03 13:35 UTC (permalink / raw) To: Michael Meissner, GCC Patches, Michael Meissner, Alan Modra On Fri, Apr 3, 2015 at 8:51 AM, Alan Modra <amodra@gmail.com> wrote: > On Thu, Apr 02, 2015 at 08:02:57PM -0400, David Edelsohn wrote: >> If the final alternative cannot occur, it should be removed as well. >> Alan, would you please test that change also? > > Tested powerpc64-linux and powerpc-linux no regressions. > > * config/rs6000/rs6000.md (extenddftf2_internal): Remove last > alternative. Okay with the two patches combined. Thanks, David ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-04-03 13:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-02 5:22 [RS6000] Fix 65576 regression Alan Modra 2015-04-02 17:03 ` David Edelsohn 2015-04-02 23:19 ` Alan Modra 2015-04-02 23:41 ` Michael Meissner 2015-04-03 0:03 ` David Edelsohn 2015-04-03 12:51 ` Alan Modra 2015-04-03 13:35 ` David Edelsohn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).