This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: reloading sums


Hi,

On Thu, 19 Jun 2003, Joern Rennecke wrote:

>         (mem:SI (plus:SI (plus:SI (reg:SI 13 r13 [471])
>                     (const_int 136 [0x88]))
>                 (reg/f:SI 14 r14)) [3 x S4 A32])) 123 {movsi_ie} (nil)
>     (expr_list:REG_DEAD (reg:SI 13 r13 [471])
>         (nil)))
>
> And it records the following reloads:
>
> (gdb) call debug_reload()
> Reload 0: reload_in (SI) = (plus:SI (reg:SI 13 r13 [471])
>                                                     (const_int 136 [0x88]))
>         GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
>         reload_in_reg: (plus:SI (reg:SI 13 r13 [471])
>                                                     (const_int 136 [0x88]))
>         reload_reg_rtx: (reg:SI 13 r13)
> Reload 1: reload_in (SI) = (reg/f:SI 14 r14)
>         R0_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
>         reload_in_reg: (reg/f:SI 14 r14)
>
> For reload 0, the constant 136 has to be loaded into a register first.
> But find_reloads has already assigned the reload register 13, which is
> also an input for the reload.

Strictly speaking this is OK, as register 13 will not be used anymore,
except for that reload.  The problem is rather, that reload doesn't see
that also the constant is not legitimate.  Why is no reload for that
constant generated?

> (insn 1481 1006 1482 57 (set (reg:SI 13 r13)
>         (const_int 136 [0x88])) -1 (nil)
>     (nil))

It's this insn which seems to be added by your particular addsi3
instruction which breaks everything.  Not reload.

> This is actually a problem for all RISC processors that have an indexed
> addressing mode - if you have a memory reference using the indexed
> addressing mode, and the base address is a pseudo containing an address
> in the frame and this pseudo fails to get a hard register, we end up
> with a double PLUS, so the frame address gets reloaded.  Now, when the
> index got a hard register, and it dies in this insn, push_reload will
> consider that hard register as a reload register, and disregrad overlaps
> with rld[n_reloads].in .  That is fine as long as the add can be done
> with a single insn, but when the constant is so large that it has to be
> reloaded into a register first, that clobbers the index.

Not necessarily.  The real condition is "if the add can be done without
clobbering it's inputs".  Well, such an add should be producable anyway.
Of course if you expand the normal add
  (set r13 (plus r13 136))
into something like
  (set r13 136)
  (set r13 (plus r13 r13))
then you have other problems than just reload.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]