------- Comment #10 from pinskia at gcc dot gnu dot org 2010-06-21 23:54 ------- (In reply to comment #9) > Hummm, I will work on your input, But now I have more questions: > > 1) Why do you call this case as explicit, and function call arguments implicit > ? The way I see it, this is a special function call (implemented with a > jump_insn to save space). So, why r11 is not a function call argument ?
Because the insn has a register reference to r11/r1/r12 :) that is the (use (match_operand: )) part of the rtx. This is unlike call instructions which don't have match_operands for function arguments. That is what I mean explicit vs implicit. > > 2) On other targets, and indirect calls, gcc generates a parallel but still > uses a call_insn to represent it. Which causes build_def_use() to avoid > register renaming of these arguments. > So other targets would not be slowed down, because those cases have to be > avoided. I mixed up insn rtl codes, woops. I thought calls was always done using jump_insn. Anyways I am saying you are hard coding a target specific information inside a target generic part of the code. This is why I think it is the wrong approach. > > 3) On the other hand, can you give me an example of a jump_insn, with a > parallel, and a symbol reference, where a register rename would be valid ? > Wouldn't all those registers be considered function call arguments ? > (Perhaps I should add a test for the existence of a symbol reference in my > patch. If the symbol reference is external or global, registers can never be > renamed !) >From i386/i386.md: (define_insn "return_indirect_internal" [(return) (use (match_operand:SI 0 "register_operand" "r"))] "reload_completed" "jmp\t%A0" [(set_attr "type" "ibr") (set_attr "length_immediate" "0")]) Though it is harder to invoke that but still it can happen if I read the code correctly (the pop needs to be greater than 64k). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
