[Mesa-dev] [PATCH 02/15] i965/fs: Don't kill ACP entries due to their generating instruction.

[Kenneth Graunke]

On 08/15/2013 10:06 AM, Paul Berry wrote:
> On 12 August 2013 13:11, Kenneth Graunke <kenneth at whitecape.org
> <mailto:kenneth at 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?