Re: conditional exec verify_live problem after scheduling

[Bernd Schmidt <bernds at redhat dot com>]

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