This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: conditional exec verify_live problem after scheduling
- To: Richard Earnshaw <rearnsha at arm dot com>
- Subject: Re: conditional exec verify_live problem after scheduling
- From: Bernd Schmidt <bernds at redhat dot com>
- Date: Fri, 12 Jan 2001 15:37:07 +0000 (GMT)
- Cc: <gcc-bugs at gcc dot gnu dot org>
On Fri, 12 Jan 2001, Richard Earnshaw wrote:
> > On Wed, 10 Jan 2001, Richard Earnshaw wrote:
> >
> > >
> > > I've come across the following problem which I think is probably related
> > > to your recent conditional-execution scheduling changes (though it may be
> > > just uncovering an underlying problem from before). The problem is in
> > > newlib/libm/common/s_modf.c when compiling arm-elf and -mhard-float.
> > [...]
> > > Now with the first sequence, the compiler thinks that r4 is live at the
> > > start of the block; with the second it doesn't. Now I believe that in
> > > both cases r4 should be dead (since a DFmode set of r3 touches both r3 and
> > > r4 in the EQ arm, and r4 is explicitly set in the NE arm), but the
> > > question is why has the schedule changed the liveness detection? Are we
> > > somehow not handling multi-register sets correctly?
> >
> > It ought to handle them correctly. Are the starting conditions identical
> > in both cases? The bitmaps at the end of the block and at the start of
> > all successor blocks must be identical before and after scheduling.
> >
> >
> > Bernd
> >
>
> Yes, After the ce2 pass the regs at the end of the block were
> ;; End of basic block 2, registers live:
> 4 [r4] 5 [r5] 6 [r6] 7 [r7] 8 [r8] 13 [sp] 14 [lr] 16 [f0]
>
> and after sched2
> ;; End of basic block 2, registers live:
> 4 [r4] 5 [r5] 6 [r6] 7 [r7] 8 [r8] 13 [sp] 14 [lr] 16 [f0]
These aren't the only relevant bits. With conditional lifetimes, flow also
examines the live set at the start of each successor block - if these have
changed, you'll possibly get a different result.
Bernd