Ian,
Thanks for the reply.
Basically GCC generates an unrecognizable instruction during reload
src/weighted_prediction.c:815:1: error: unrecognizable insn:
(insn 1716 1715 680 84 src/weighted_prediction.c:729 (set (reg:SI 4 r4)
(plus:SI (mult:SI (reg:SI 9 r9)
(const_int 8 [0x8]))
(reg:SI 4 r4))) -1 (nil))
from gen_reload function.
/* Otherwise, just write (set OUT IN) and hope for the best. */
else
emit_insn (gen_rtx_SET (VOIDmode, out, in));
The comment doesn’t sound very convincing to me.
From debug message:
Reloads for insn # 680
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 57 r57)
(const_int 40 [0x28]))
GR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 57 r57)
(const_int 40 [0x28]))
reload_reg_rtx: (reg:SI 4 r4)
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 57 r57)
(const_int 78396 [0x1323c]))
GR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (plus:SI (reg/f:SI 57 r57)
(const_int 78396 [0x1323c]))
reload_reg_rtx: (reg:SI 6 r6)
Reload 2: reload_in (SI) = (mem/c:SI (plus:SI (reg/f:SI 57 r57)
(const_int 78396
[0x1323c])) [50 %sfp+78252 S4 A32])
GR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (reg:SI 596 [ ivtmp.474 ])
reload_reg_rtx: (reg:SI 9 r9)
Reload 3: reload_in (SI) = (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
(const_int 8 [0x8]))
(plus:SI (reg/f:SI 57 r57)
(const_int 40 [0x28])))
GR_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 8
reload_in_reg: (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
(const_int 8 [0x8]))
(plus:SI (reg/f:SI 57 r57)
(const_int 40 [0x28])))
reload_reg_rtx: (reg:SI 4 r4)
I don’t understand why Reload 3 is necessary. After reload 0, 1, 2,
The following expression already fits into our addressing mode.
(plus:SI (mult:SI (reg:SI 9 r9) (const_int 8 [0x8]))
(reg:SI 4 r4))
Instead GCC tries to generate invalid
(insn 1716 1715 680 84 src/weighted_prediction.c:729 (set (reg:SI 4 r4)
(plus:SI (mult:SI (reg:SI 9 r9)
(const_int 8 [0x8]))
(reg:SI 4 r4))) -1 (nil))
and load from [r4] subsequently.
Bingfeng
> -----Original Message-----
> From: Ian Lance Taylor [mailto:[email protected]]
> Sent: 17 December 2010 01:26
> To: Bingfeng Mei
> Cc: [email protected]
> Subject: Re: Is eliminate_regs_in_insn allowed to generate invalid
> instruction?
>
> "Bingfeng Mei" <[email protected]> writes:
>
> > I was hit by an ICE in reload. You know how difficult to debug it ☺.
> >
> > My primary suspect is that eliminate_regs_in_insn transforms
> >
> >
> > (insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
> > (mem:DF (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
> > (const_int 8 [0x8]))
> > (reg/f:SI 1105)) [3 S8 A8])) 448 {*ldl_dfmode} (nil))
> >
> >
> > To:
> > (insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
> > (mem:DF (plus:SI (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
> > (const_int 8 [0x8]))
> > (reg/f:SI 57 r57))
> > (const_int 40 [0x28])) [3 S8 A8])) 448 {*ldl_dfmode}
> (nil))
> >
> > The latter has illegal memory address mode, and r57 is our stack
> pointer.
> >
> > Since reload part is still half mystery to me, I wonder whether this
> is an
> > wrong transformation and causes the following ICE. Is it allowed that
> > Eliminate_regs_in_insn to generate such illegal instruction?
>
> It's normal for reload to produce instructions with invalid operands
> during its operation, with the expectation that the invalid operands
> will be reloaded into registers before the pass is complete. I
> couldn't
> see the specific ICE in your message, so I don't know if that is what
> is
> happening here.
>
> Ian
