On Thu, Apr 2, 2015 at 7:41 PM, Michael Meissner <meiss...@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
