This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A question about df_get_live_in
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 14 Jul 2009 00:07:58 +0200
- Subject: Re: A question about df_get_live_in
- References: <20090714.064618.217955193.kkojima@rr.iij4u.or.jp>
On Mon, Jul 13, 2009 at 11:46 PM, Kaz Kojima<kkojima@rr.iij4u.or.jp> wrote:
> Hi,
>
> I hope DF/middle-end experts will comment about this.
>
> PR target/40710
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710
>
> is a wrong code problem on SH. ?A delayed slot of a conditional
> branch insn is wrongly filled with an insn changing stack pointer
> in the failing case. ?I've tried to see what is going on.
You found out why the dbr-sched pass (reorg.c) needs a rewrite so
badly. DF needs a CFG, and reorg.c refuses to maintain a valid CFG. In
other words, it just doesn't work very well together. See PR39938,
PR40086, etc...
Basically, as long as on-one is willing to put up the resources to
beat sense into reorg.c, you'll probably continue to find bugs related
to delay slot filling.
Anyway, the bug here is probably somewhere between .compgotos and
reorg, because from your dump we have:
;; Start of basic block ( 0) -> 2
;; live in 4 [r4] 5 [r5] 6 [r6] 146 [pr]
;; live out 1 [r1] 2 [r2] 3 [r3] 4 [r4] 5 [r5] 6 [r6] 15 [r15]
;; Start of basic block ( 2) -> 3
;; live in 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 15 [r15]
;; live out 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 7 [r7] 15 [r15]
So when the CFG is still valid, r15 is live-out in basic block 2 and
live-in in basic block 3 (which contains insns 32, whatever that means
for an invalid CFG). For which bb does mark_target_live_regs call
df_get_live_in?
Ciao!
Steven