On 18/05/2010 15:24, Paulo J. Matos wrote:
> On Tue, May 18, 2010 at 3:26 PM, Dave Korn <[email protected]> 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
