[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.

pinskia at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Mon Jun 21 23:54:00 GMT 2010



------- 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



More information about the Gcc-bugs mailing list