Re: [RS6000] Fix 65576 regression

[Michael Meissner <meissner@linux.vnet.ibm.com>]

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