Re: Unexpected output constraints
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. [...] 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))] That's untested however. Bernd
Re: Unexpected output constraints
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
Re: Unexpected output constraints
On 04/01/2010 11:08 PM, Daniel Jacobowitz wrote: (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))] That doesn't work either, a matching constraint has to be an input. Also, legitimize_tls_address is calling it with the same reg for both operands, which is going to lead to tears if they're both outputs. So, maybe simply (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 0,0) (const_int 4) (match_operand 2 )] UNSPEC_PIC_BASE)))] but on the other hand maybe it's best to find whoever wrote the pattern and ask them what's going on. Bernd
Re: Unexpected output constraints
On Fri, Apr 02, 2010 at 12:27:33AM +0100, Bernd Schmidt wrote: That doesn't work either, a matching constraint has to be an input. i386 uses this, so I figure it's OK. Also, legitimize_tls_address is calling it with the same reg for both operands, which is going to lead to tears if they're both outputs. Hrm. Yeah, those really should be two pseudos. I'll fix that. -- Daniel Jacobowitz CodeSourcery
