[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