This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: extra machine-dependent passes
On Tue, Jun 19, 2001 at 05:00:39PM -0400, DJ Delorie wrote:
> The purpose of this code is to add the SETs at the beginning of the
> function's RTL, before the FUNCTION_BEG note. This is the same place
> where arguments are copied out of their hard regs and is not included
> in the insns that get inlined.
>
> This is the same code all the backends use for doing this.
Err, no, the backends use this sequence to put the initialization
code before the first possible use. The FUNCTION_BEG note is
rather irrelevant.
> The rtl emitted here goes *before* the FUNCTION_BEG note and thus will
> not be included in the set of insns inlined.
I beg to differ. Consider
static void *data;
extern void f0(void);
static inline void f1(void)
{
data = __builtin_return_address(0);
}
static void f2(void)
{
f0();
f1();
}
compiled on Alpha, which uses the push_to_toplevel sequence
described above. In the .00.rtl dump we find
;; Function f1
(note 2 0 8 NOTE_INSN_DELETED)
(insn 8 2 3 (set (reg:DI 69)
(reg:DI 26 $26)) -1 (nil)
(nil))
(note 3 8 10 NOTE_INSN_FUNCTION_BEG)
(insn 10 3 12 (set (reg/f:DI 70)
(symbol_ref:DI ("data"))) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:DI ("data"))
(nil)))
(insn 12 10 13 (set (mem/f:DI (reg/f:DI 70) 2)
(reg:DI 69)) -1 (nil)
(nil))
[...]
;; Function f2
(note 2 0 3 NOTE_INSN_DELETED)
(note 3 2 8 NOTE_INSN_FUNCTION_BEG)
(call_insn 8 3 10 (parallel[
(call (mem:DI (symbol_ref:DI ("f0")) 0)
(const_int 0 [0x0]))
(clobber (reg:DI 27 $27))
(clobber (reg:DI 26 $26))
] ) -1 (nil)
(nil)
(nil))
(note 10 8 12 0x200003b2300 NOTE_INSN_BLOCK_BEG)
(insn/i 12 10 13 (set (reg:DI 69)
(reg:DI 26 $26)) -1 (nil)
(nil))
(insn/i 13 12 14 (set (reg/f:DI 70)
(symbol_ref:DI ("data"))) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:DI ("data"))
(nil)))
(insn/i 14 13 15 (set (mem/f:DI (reg/f:DI 70) 2)
(reg:DI 69)) -1 (nil)
(nil))
[...]
Insn 8 from f1 is indeed present as insn 12 in f2. QED.
> This is the same spot where gcc puts the moves from the argument
> hard regs to the argument pseudos.
Arguments -- and only arguments -- are handled specially.
> I can't remember ever suggesting a set of a hard register. I've been
> using constraints to get the values I need *into* the hard regs, and
> the optimizer handles those just fine. The code I'm adding is only
> for getting values *out* of hard regs.
Consider a target for which the pic register is set via a
pc-relative computation. E.g. m68k where we use
lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
i.e. "a5 = pc+magic". Now, your bits only allow us to do a
plain copy from a hard register into a pseudo. Which would
force us to calculate the value into %a5 first. There's no
reason we can't put this value into the pseudo to start with.
r~