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: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
