This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #4


Hi Mike,

On Fri, Mar 16, 2018 at 12:50:45PM -0400, Michael Meissner wrote:
> --- gcc/config/rs6000/rs6000-output.c	(revision 258576)
> +++ gcc/config/rs6000/rs6000-output.c	(working copy)
> @@ -162,7 +162,13 @@ rs6000_output_move_64bit (rtx operands[]
>  
>        /* Moves to SPRs.  */
>        else if (reg_is_spr_p (dest))
> -	return "mt%0 %1";
> +	{
> +	  if (src_gpr_p)
> +	    return "mt%0 %1";
> +
> +	  else if (dest_regno == src_regno)
> +	    return "nop";
> +	}
>      }

Is this correct?  Many SPRs are not simple registers, they do something
when you write to them.  But I guess this is only for lr,ctr,vrsave (i.e.
regclass "h", "SPECIAL_REGS").  So maybe we want a better name?

> +;;           STD      LD       MR      MT<SPR> MF<SPR> G-const
> +;;           H-const  F-const  Special
> +
>  (define_insn "*mov<mode>_softfloat64"
> -  [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,cl,r,r,r,r,*h")
> -	(match_operand:FMOVE64 1 "input_operand" "r,Y,r,r,h,G,H,F,0"))]
> +  [(set (match_operand:FMOVE64 0 "nonimmediate_operand"
> +           "=Y,       r,      r,      cl,     r,      r,
> +             r,       r,      *h")
> +
> +	(match_operand:FMOVE64 1 "input_operand"
> +            "r,       Y,      r,      r,      h,      G,
> +             H,       F,      0"))]
> +
>    "TARGET_POWERPC64 && TARGET_SOFT_FLOAT
> -   && (gpc_reg_operand (operands[0], <MODE>mode)
> -       || gpc_reg_operand (operands[1], <MODE>mode))"
> -  "@
> -   std%U0%X0 %1,%0
> -   ld%U1%X1 %0,%1
> -   mr %0,%1
> -   mt%0 %1
> -   mf%1 %0
> -   #
> -   #
> -   #
> -   nop"
> -  [(set_attr "type" "store,load,*,mtjmpr,mfjmpr,*,*,*,*")
> -   (set_attr "length" "4,4,4,4,4,8,12,16,4")])
> +   && rs6000_valid_move_p (operands[0], operands[1])"
> +  "* return rs6000_output_move_64bit (operands);"
> +  [(set_attr "type"
> +            "store,   load,   *,      mtjmpr, mfjmpr, *,
> +             *,       *,      *")
> +
> +   (set_attr "length"
> +            "4,       4,      4,      4,      4,      8,
> +             12,      16,     4")])

Let's take this one as example.  The attributes depend on which alternative
is selected, but with your change the actual output insn does not.  That is
no good.

Maybe you can reduce the number of alternatives?  Make it just store,
load, and moves for example, and then select the attributes based on what
machine insns you actually output?  The ones that are split are the
problematic ones in that case, the rest is easy to handle.


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]