On Fri, Apr 02, 2010 at 12:06:28AM +0100, Bernd Schmidt wrote:
> On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote:
> > I'm debugging a Thumb-2 glibc build failure on trunk for
> > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
> > 2010-02-01 patch for TLS patterns, which includes this:
> >
> > (define_insn "tls_load_dot_plus_four"
> > [(set (match_operand:SI 0 "register_operand" "=l,r")
> > (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r")
> > (const_int 4)
> > (match_operand 2 "" "")]
> > UNSPEC_PIC_BASE)))]
> >
> > It's that "+" on the second operand. It should just be "&", and I
> > think that will fix the failure (I'll test it shortly).
>
> That can't be right, "&" only makes sense for outputs.
Yeah, suitable juggling in match_scratch was what I really needed:
(define_insn "tls_load_dot_plus_four"
[(set (match_operand:SI 0 "register_operand" "=l,r")
(mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "l,r")
(const_int 4)
(match_operand 2 "" "")]
UNSPEC_PIC_BASE)))
(clobber (match_scratch:SI 3 "=&1,&1"))]
> > It seems to me that the problem is marking a register in the RHS of a
> > set as an output constraint.
>
> Yes. There was a similar bug for tls_load_dot_plus_eight recently. In
> this case it seems that operand 1 is in fact both read and written by
> the pattern, so the pattern should be something like
>
> [(set (match_operand:SI 0 "register_operand" "=l,r")
> (mem:SI (unspec:SI [(match_dup 1)
> (const_int 4)
> (match_operand 2 "" "")]
> UNSPEC_PIC_BASE)))
> (clobber (match_operand:SI 1 "register_operand" "+&l,&r"))]
Is there a reason to prefer one of these forms over the other?
match_scratch / match_dup always make me ask that question :-)
--
Daniel Jacobowitz
CodeSourcery
