Re: ssa bootstrap problem on x86 (cmpstrsi_1 pattern)

[Richard Earnshaw <rearnsha@arm.com>]

> >   I've looked at the SSA bootstrap problem.  It's caused by an insn
> >   in the x86 backend which looks like:
> > 
> > Thanks for tracking this down.
> > 
> >   (define_insn "cmpstrsi_1"
> >     [(set (reg:CC 17)
> > 	  (if_then_else:CC (ne (match_operand:SI 2 "register_operand" "c")
> > 			       (const_int 0))
> > 	    (compare:SI (mem:BLK (match_operand:SI 0 "address_operand" "S"))
> > 			(mem:BLK (match_operand:SI 1 "address_operand" "D")))
> > 	    (const_int 0)))
> >      (use (match_operand:SI 3 "immediate_operand" "i"))
> >      (use (reg:CC 17))
> >      (use (reg:SI 19))
> >      (clobber (match_dup 0))
> >      (clobber (match_dup 1))
> >      (clobber (match_dup 2))]
> >   ...)
> > 
> >   The problem here is the match_dups.  IMHO, it would be much better if
> >   these were written as match_scratch with '0', '1', and '2'
> >   constraints.
> > 

I've been talking over a similar problem on the ARM with RTH.  From my 
understanding, you cannot have a match_dup that ties an input to an output 
of the same insn if you want to be able to convert the insn to SSA form.  
You might be able to rewrite the above using ties: eg

   (define_insn "cmpstrsi_1"
     [(set (reg:CC 17)
 	  (if_then_else:CC (ne (match_operand:SI 5 "register_operand" "2")
 			       (const_int 0))
 	    (compare:SI (mem:BLK (match_operand:SI 3 "address_operand" "0"))
 			(mem:BLK (match_operand:SI 4 "address_operand" "1")))
 	    (const_int 0)))
      (use (match_operand:SI 3 "immediate_operand" "i"))
      (use (reg:CC 17))
      (use (reg:SI 19))
      (clobber (match_operand:SI 0 "address_operand" "+S"))
      (clobber (match_operand:SI 1 "address_operand" "+D"))
      (clobber (match_operand:SI 2 "register_operand" "+c"))]

Reload will then generate the necessary ties and reloads as required.

R.