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
