[RS6000] "G" and "H" constraints

The patch fixes two cases where the "G" and "H" constraints were used
incorrectly.  Their purpose is calculating insn lengths.  Thus it
never makes sense to put "GH" together or with "F" in an insn
alternative.

movdi_internal32 used "GHF" in an alternative so I replaced that with
"F", and added length attributes for the insn, which were missing.
There are some formatting changes too, to make alternatives line up
with attributes.

The FMOVE128 version of mov<mode>_softfloat also had "GHF" in an
alternative, so "GH" is dropped and "F" moved to a separate
alternative in order to get insn lengths correct.  Well by correct I
mean we need to choose the maximum insn length otherwise branches
might not reach.  Note the very large length for "F".  I think it
would be better to force soft-float long double constants to memory in
64-bit mode, but that's a patch for another day.

Bootstrapped etc. powerpc64le-linux.

	* config/rs6000/constraints.md (G, H): Comment on purpose of
	constraint.  Correct mode comments.
	* config/rs6000/rs6000.md (movdi_internal32): Remove "GH" from
	alternative handling "F".  Add length attr.  Formatting.
	(mov<mode>_softfloat128): Renamed FMOVE128 mov<mode>_softfloat.
	Delete "GH" from alternative, and move "F" to separate alternative.
	Correct insn lengths.

Hi!

On Sun, Nov 25, 2018 at 10:44:00PM +1030, Alan Modra wrote:
> The patch fixes two cases where the "G" and "H" constraints were used
> incorrectly.  Their purpose is calculating insn lengths.  Thus it
> never makes sense to put "GH" together or with "F" in an insn
> alternative.
> 
> movdi_internal32 used "GHF" in an alternative so I replaced that with
> "F", and added length attributes for the insn, which were missing.
> There are some formatting changes too, to make alternatives line up
> with attributes.
> 
> The FMOVE128 version of mov<mode>_softfloat also had "GHF" in an
> alternative, so "GH" is dropped and "F" moved to a separate
> alternative in order to get insn lengths correct.  Well by correct I
> mean we need to choose the maximum insn length otherwise branches
> might not reach.  Note the very large length for "F".  I think it
> would be better to force soft-float long double constants to memory in
> 64-bit mode, but that's a patch for another day.
> 
> Bootstrapped etc. powerpc64le-linux.
> 
> 	* config/rs6000/constraints.md (G, H): Comment on purpose of
> 	constraint.  Correct mode comments.
> 	* config/rs6000/rs6000.md (movdi_internal32): Remove "GH" from
> 	alternative handling "F".  Add length attr.  Formatting.
> 	(mov<mode>_softfloat128): Renamed FMOVE128 mov<mode>_softfloat.
> 	Delete "GH" from alternative, and move "F" to separate alternative.
> 	Correct insn lengths.


> -;; Floating-point constraints
> +;; Floating-point constraints.  These two are defined so that insn
> +;; length attributes can be calculated exactly.
>  
>  (define_constraint "G"
> -  "Constant that can be copied into GPR with two insns for DF/DI
> -   and one for SF."
> +  "Constant that can be copied into GPR with two insns for DF/DD
> +   and one for SF/SD."
>    (and (match_code "const_double")
>         (match_test "num_insns_constant (op, mode)
>  		    == (mode == SFmode ? 1 : 2)")))

The code does 2 for SDmode, the comment says 1.  Which is correct?

> -(define_insn_and_split "*mov<mode>_softfloat"
> -  [(set (match_operand:FMOVE128 0 "nonimmediate_operand" "=Y,r,r")
> -	(match_operand:FMOVE128 1 "input_operand" "r,YGHF,r"))]
> +(define_insn_and_split "*mov<mode>_softfloat128"
> +  [(set (match_operand:FMOVE128 0 "nonimmediate_operand" "=Y,r,r,r")
> +	(match_operand:FMOVE128 1 "input_operand" "r,Y,F,r"))]

There is <mode> as part of the name already; what does adding "128" help?

>    "TARGET_SOFT_FLOAT
>     && (gpc_reg_operand (operands[0], <MODE>mode)
>         || gpc_reg_operand (operands[1], <MODE>mode))"
> @@ -7721,7 +7721,19 @@ (define_insn_and_split "*mov<mode>_softfloat"
>    "&& reload_completed"
>    [(pc)]
>  { rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
> -  [(set_attr "length" "20,20,16")])
> +  [(set_attr_alternative "length"
> +       [(if_then_else (match_test "TARGET_POWERPC64")
> +	    (const_string "8")
> +	    (const_string "16"))
> +	(if_then_else (match_test "TARGET_POWERPC64")
> +	    (const_string "8")
> +	    (const_string "16"))
> +	(if_then_else (match_test "TARGET_POWERPC64")
> +	    (const_string "40")
> +	    (const_string "32"))
> +	(if_then_else (match_test "TARGET_POWERPC64")
> +	    (const_string "8")
> +	    (const_string "16"))])])

Does -mpowerpc64 really use more insns for F than -mno-powerpc64 does?  Huh.

> @@ -8656,22 +8668,22 @@ (define_insn_and_split "reload_gpr_from_vsxsf"
>  ;; Use of fprs is disparaged slightly otherwise reload prefers to reload
>  ;; a gpr into a fpr instead of reloading an invalid 'Y' address
>  
> -;;        GPR store  GPR load   GPR move   FPR store  FPR load    FPR move
> -;;        GPR const  AVX store  AVX store  AVX load   AVX load    VSX move
> -;;        P9 0       P9 -1      AVX 0/-1   VSX 0      VSX -1      P9 const
> +;;        GPR store  GPR load   GPR move   FPR store   FPR load    FPR move
> +;;        GPR const  AVX store  AVX store  AVX load    AVX load    VSX move
> +;;        P9 0       P9 -1      AVX 0/-1   VSX 0       VSX -1      P9 const
>  ;;        AVX const  
>  
>  (define_insn "*movdi_internal32"
>    [(set (match_operand:DI 0 "nonimmediate_operand"
> -         "=Y,        r,         r,         m,         ^d,         ^d,
> -          r,         wY,        Z,         ^wb,       $wv,        ^wi,
> -          *wo,       *wo,       *wv,       *wi,       *wi,        *wv,
> +         "=Y,        r,         r,         m,          ^d,         ^d,
> +          r,         wY,        Z,         ^wb,        $wv,        ^wi,
> +          *wo,       *wo,       *wv,       *wi,        *wi,        *wv,
>            *wv")
>  
>  	(match_operand:DI 1 "input_operand"
> -         "r,         Y,         r,         ^d,        m,          ^d,
> -          IJKnGHF,   ^wb,       $wv,       wY,        Z,          ^wi,
> -          Oj,        wM,        OjwM,      Oj,        wM,         wS,
> +         "r,         Y,         r,         ^d,         m,          ^d,
> +          IJKnF,     ^wb,       $wv,       wY,         Z,          ^wi,
> +          Oj,        wM,        OjwM,      Oj,         wM,         wS,
>            wB"))]
>  
>    "! TARGET_POWERPC64
> @@ -8698,11 +8710,16 @@ (define_insn "*movdi_internal32"
>     #
>     #"
>    [(set_attr "type"
> -               "store,     load,      *,         fpstore,    fpload,     fpsimple,
> -                *,         fpstore,   fpstore,   fpload,     fpload,     veclogical,
> -                vecsimple, vecsimple, vecsimple, veclogical, veclogical, vecsimple,
> -                vecsimple")
> -   (set_attr "size" "64")])
> +         "store,     load,      *,         fpstore,    fpload,     fpsimple,
> +          *,         fpstore,   fpstore,   fpload,     fpload,     veclogical,
> +          vecsimple, vecsimple, vecsimple, veclogical, veclogical, vecsimple,
> +          vecsimple")
> +   (set_attr "size" "64")
> +   (set_attr "length"
> +         "8,         8,         8,         4,          4,          4,
> +          16,        4,         4,         4,          4,          4,
> +          4,         4,         4,         4,          4,          8,
> +          4")])

Please don't make some columns wider than others.  You could just remove
the space after "veclogical,", maybe?

Looks good otherwise.  Please fix that SDmode thing and the 128 thing?
Okay for trunk with that, thanks!


Segher

On Wed, Nov 28, 2018 at 11:55:21AM -0600, Segher Boessenkool wrote:
> >  (define_constraint "G"
> > -  "Constant that can be copied into GPR with two insns for DF/DI
> > -   and one for SF."
> > +  "Constant that can be copied into GPR with two insns for DF/DD
> > +   and one for SF/SD."
> >    (and (match_code "const_double")
> >         (match_test "num_insns_constant (op, mode)
> >  		    == (mode == SFmode ? 1 : 2)")))
> 
> The code does 2 for SDmode, the comment says 1.  Which is correct?

The comment is correct.  I'll fix the code to do
"mode == SFmode || mode == SDmode".