------- Comment #11 from edmar at freescale dot com 2010-06-22 16:53 ------- (In reply to comment #10) > 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.
Ok. > 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. I understand your point of view. But I am still convinced that a jump_insn with a parallel and symbol reference (external or global) cannot have the explicit registers renamed, regardless of the target architecture. Now, if powerpc is the only target that can generate such a rtl (jump_insn, with external symbol reference), then I have to agree with you... > (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). This was close, but it has no symbol reference. Therefore it is ok to rename the register, because the use of the register is in the "jmp" instruction and not inside the code that the "jmp" points to. (i.e., this insn is not passing an argument to a function). Ok, I have to change my patch, but before I do that, I want to make sure we agree on the details. Is it safe to assume that powerpc is the only target that can generate such a rtl ? If not, I will modify the patch to add a test that checks if there is a symbol reference. If it is, I will scratch all this, and will make the powerpc target generate a call_insn instead of a jump_insn (At this point we agree that reg rename cannot swallow a jump_insn, right ?) Thanks, Edmar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
