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