Re: unrecognizable insn after adding clobbers

2010-05-18 Thread Dave Korn
On 18/05/2010 13:01, Paulo J. Matos wrote:

 I have for call_value a define_expand and define_insn that look like:
 (define_expand call_value
  [
 (set (match_operand 0  )
  (call (match_operand:QI 1 nonmemory_operand )
(match_operand:QI 2 immediate_operand )))
  ]
  
  )
 

 (define_insn *call_value
   [
 (set (match_operand 0  )
  (call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
   ]
   !TARGET_X
 {
   return target_call(operands); // deals with op0, 1 and 2.
 })
 
 (define_insn *call_value_complex
   [
 (set (match_operand 0  )
  (call (mem:QI (match_operand:HI 1 callable_operand yY,i))
(match_operand:QI 2 immediate_operand i,i)))
 (clobber (match_scratch:QI 3 y,y))
 (clobber (match_scratch:QI 4 y,y))
   ]
   TARGET_X
 {
 return target_complex_call(operands); // deals with op0, 1, 2, 3, and 4.
 })
 
 This however causes an unrecognizable insn error during the compiler
 runtime when I have TARGET_X defined.
 I was expecting the clobbers not to influence the recognition but it
 seems I was wrong.

  Actually, IIUC the clobbers don't influence the recognition, that is
correct, so both those patterns look identical to the recognizer and
effectively only the first one will ever be matched by combine, then too late
the target condition kicks in and the second one pops up and goes oi, where's
my clobbers?.  Or something like that.

  I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex
: gen_call_value); DONE in your expander.

cheers,
  DaveK



Re: unrecognizable insn after adding clobbers

2010-05-18 Thread Paulo J. Matos
On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:

 This however causes an unrecognizable insn error during the compiler
 runtime when I have TARGET_X defined.
 I was expecting the clobbers not to influence the recognition but it
 seems I was wrong.

  Actually, IIUC the clobbers don't influence the recognition, that is
 correct, so both those patterns look identical to the recognizer and
 effectively only the first one will ever be matched by combine, then too late
 the target condition kicks in and the second one pops up and goes oi, where's
 my clobbers?.  Or something like that.


Got it, thanks for the explanation. It makes sense.

  I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex
 : gen_call_value); DONE in your expander.


So I guess i need something like
emit_call_insn(TARGET_X ? gen_call_value_complex(...) :
gen_call_value(...)); DONE

but what do I pass to the gen_* functions? I don't really have
anything to pass to them at this point, I just want gcc to expand
those. However if I pass no arguments it claims I haven't passed
enough arguments.

-- 
PMatos


Re: unrecognizable insn after adding clobbers

2010-05-18 Thread Dave Korn
On 18/05/2010 15:24, Paulo J. Matos wrote:
 On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
 This however causes an unrecognizable insn error during the compiler
 runtime when I have TARGET_X defined.
 I was expecting the clobbers not to influence the recognition but it
 seems I was wrong.
  Actually, IIUC the clobbers don't influence the recognition, that is
 correct, so both those patterns look identical to the recognizer and
 effectively only the first one will ever be matched by combine, then too late
 the target condition kicks in and the second one pops up and goes oi, 
 where's
 my clobbers?.  Or something like that.

 
 Got it, thanks for the explanation. It makes sense.
 
  I think what you need to do is explicitly (TARGET_X ? gen_call_value_complex
 : gen_call_value); DONE in your expander.

 
 So I guess i need something like
 emit_call_insn(TARGET_X ? gen_call_value_complex(...) :
 gen_call_value(...)); DONE
 
 but what do I pass to the gen_* functions? I don't really have
 anything to pass to them at this point, I just want gcc to expand
 those. However if I pass no arguments it claims I haven't passed
 enough arguments.

  They need the contents of the operands[] array passed to them, and you'll
have to allocate the scratch registers (as pseudos) yourself, I guess (which
of course means you can't generate these after reload, should you ever want
to).  Hmm, I'm not so sure of my answer now, maybe I'm forgetting something.
I do remember having trouble trying to make an insn work with two variants
that different only in clobbers before.

cheers,
  DaveK