On 18 August 2013 17:06, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On 08/15/2013 10:06 AM, Paul Berry wrote: > >> On 12 August 2013 13:11, Kenneth Graunke <kenn...@whitecape.org >> <mailto:kenn...@whitecape.org>**> wrote: >> >> fs_copy_prop_dataflow::setup_**kills() walks through each basic >> block's >> instructions, looking for instructions which overwrite registers used >> in ACP entries. >> >> This would be fine, except that it didn't exclude the instructions >> which generated the ACP entries in the first place. This meant that >> every copy was killed by its own generating instruction, making the >> dataflow analysis useless. >> >> >> I don't think this is actually a problem, because the bd[b].kills bits >> are only used to prevent liveness information from being propagated from >> bd[b].livein to bd[b].liveout, and the fs_copy_prop_dataflow constructor >> initializes bd[b].liveout with the set of ACP's that are generated from >> block b. >> > > It doesn't by the end of the series, but I think that's moot... Fair point. > > > So the only situation in which your patch would allow liveness >> information to be propagated from bd[b].livein to bd[b].liveout is for >> bits in bd[b].liveout that are already set. >> >> Or am I misunderstanding things? >> > > I think you're right that this is unnecessary. The user of kill is: > > bd[b].liveout[i] = > bd[b].copy[i] | (bd[b].livein[i] & ~bd[b].kill[i]); > > So even though copies are marked as killed, they'll be reintroduced as > liveout due to the union with the COPY set. With the rest of the bugs in > the algorithm fixed, dropping this patch makes no difference. > > I'm happy to drop it. Would you prefer that? > Yeah, I think I have a minor preference for dropping it. But I won't press the issue.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
