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...
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?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
