This is the mail archive of the 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: A question about df_get_live_in

On Mon, Jul 13, 2009 at 11:46 PM, Kaz Kojima<> wrote:
> Hi,
> I hope DF/middle-end experts will comment about this.
> PR target/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


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