This is the mail archive of the gcc-patches@gcc.gnu.org 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: RFA: PR 34415: dbr_schedule vs. uninitialised registers


Eric Botcazou <ebotcazou@libertysurf.fr> 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 
> [$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.

Richard


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