This is the mail archive of the
mailing list for the GCC project.
Re: RFA: PR 34415: dbr_schedule vs. uninitialised registers
Eric Botcazou <firstname.lastname@example.org> writes:
>> This doesn't work when the fallthrough entry to a loop leaves a register
>> R uninitialised. Suppose X is in the loop, but before the first set of
>> R, and that the liveness computation starts outside the loop. In this
>> situation, we won't notice that R is live, and so we might decide that
>> it is safe to put a set of R in the delay slot of a conditional branch.
>> (This didn't used to be a problem, because we'd make R live from the
>> start of the function to the start of the loop. We're more accurate
>> now though, and that's obviously a good thing.)
> Isn't it simply the case that we use the wrong DF problem here, namely LIVE
> instead of LR?
> ;; End of basic block 2 -> ( 3)
> ;; lr out 4 [$4] 6 [$6] 7 [$7] 8 [$8] 9 [$9] 10 [$10] 28 [$28] 29 [$sp] 31
> ;; live out 4 [$4] 6 [$6] 7 [$7] 9 [$9] 10 [$10] 31 [$31]
Well, that would work too, but would make the register unnecessarily
live in cases where my patch wouldn't (i.e. between the barrier and
the place where the register really does become live). I'm happy
to do it that way instead if you prefer though.