This is the mail archive of the gcc@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: Reload generate invalid instruction on ppc64


Another problem is in the definition of insn pattern "*movdi_internal64".

(define_insn "*movdi_internal64"
  [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wm")
        (match_operand:DI 1 "input_operand"
"r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wm,r"))]
  "TARGET_POWERPC64
   && (gpc_reg_operand (operands[0], DImode)
       || gpc_reg_operand (operands[1], DImode))"
  "@
   std%U0%X0 %1,%0
   ld%U1%X1 %0,%1
   mr %0,%1
   li %0,%1
   lis %0,%v1
   #
   stfd%U0%X0 %1,%0
   lfd%U1%X1 %0,%1
   fmr %0,%1
   mf%1 %0
   mt%0 %1
   nop
   mftgpr %0,%1
   mffgpr %0,%1
   mfvsrd %0,%x1
   mtvsrd %x0,%1"
  [(set_attr "type"
"store,load,*,*,*,*,fpstore,fpload,fp,mfjmpr,mtjmpr,*,mftgpr,mffgpr,mftgpr,mffgpr")
   (set_attr "length" "4,4,4,4,4,20,4,4,4,4,4,4,4,4,4,4")])

The predicates of this insn pattern allow the moving of an integer to
VSX register, but there is no constraint allow this case. Can this
cause problem in reload?

thanks
Guozhi Wei

On Mon, Jul 28, 2014 at 5:49 PM, Carrot Wei <carrot@google.com> wrote:
> Hi Vlad
>
> When I use ppc64 gcc4.9 to compile an internal application I got an
> ICE due to an invalid instruction generated by reload.
>
> Before IRA, I have following insns:
>
> (insn 139 136 581 10 (set (reg:DI 567)
>         (const_int 0 [0])) ./strings/stringpiece.h:205 discrim 1 520
> {*movdi_internal64}
>      (expr_list:REG_EQUIV (const_int 0 [0])
>         (nil)))
>
> ...
>
> (insn 231 1062 237 24 (set (reg:V2DI 401 [ vect_cst_.7586 ])
>         (vec_concat:V2DI (reg:DI 235 [ fprint$lo_ ])
>             (reg:DI 567))) 1066 {vsx_concat_v2di}
>      (expr_list:REG_DEAD (reg:DI 235 [ fprint$lo_ ])
>         (expr_list:REG_EQUAL (vec_concat:V2DI (reg:DI 235 [ fprint$lo_ ])
>                 (const_int 0 [0]))
>             (nil))))
>
> IRA decides register r567 should be spilled into memory
>
>        a48(r567,l0)  -- assign memory
>     48:r567 l0   mem
>
>
> Later reload pass reload constant 0 into hard floating point r42 directly
>
> (insn 1086 1062 231 24 (set (reg:DI 42 10)
>         (const_int 0 [0])) 520 {*movdi_internal64}
>      (nil))
>
> (insn 231 1086 237 24 (set (reg:V2DI 32 0 [orig:401 vect_cst_.7586 ] [401])
>         (vec_concat:V2DI (reg:DI 32 0 [orig:235 fprint$lo_ ] [235])
>             (reg:DI 42 10))) 1066 {vsx_concat_v2di}
>      (expr_list:REG_EQUAL (vec_concat:V2DI (reg:DI 32 0 [orig:235
> fprint$lo_ ] [235])
>             (const_int 0 [0]))
>         (nil)))
>
> Unfortunately insn 1086 doesn't satisfy the constraints of insn
> pattern movdi_internal64, so causing an ICE in later pass.
>
>
> The reload insn 1086 is generated by following code in function
> reload1.c:gen_reload
>
>   /* If IN is a simple operand, use gen_move_insn.  */
>   else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
>     {
>       tem = emit_insn (gen_move_insn (out, in));
>       /* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note.  */
>       mark_jump_label (in, tem, 0);
>     }
>
> After generating the move insn, reload doesn't check if the insn is
> valid or if it can satisfy constraints. On ppc64 we can't load a
> constant into fp/vsx register directly. Is it a bug here?
>
> thanks a lot
> Guozhi Wei


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