[Mesa-dev] Plan to work on opt_peephole_sel optimization for vec4

[Antía Puentes]

Hi Matt,

thanks for your suggestions.

On dom, 2015-10-11 at 10:35 -0700, Matt Turner wrote:
> I don't believe it's valuable to port the opt_peephole_sel() pass to
> the vec4 backend. With NIR (since NIR essentially performs the same
> optimization), the opt_peephole_sel() pass only improves code
> generation on Gen < 7 (where we use MRFs) in cases like
> 
> (+f0) if
> mov m1, ...
> mov m2, ...
> send ..., m1
> else
> mov m1, ...
> mov m2, ...
> send ..., m1
> endif
> 
> where the two sends are texture operations using the same coordinate
> but different samplers. On Gen7+ where send-from-GRF, the source
> payload for the two sends will be different registers and
> opt_peephole_sel() won't handle it.
> 
> That said, we still do send-from-MRF on all platforms in the vec4
> backend, but texturing is sufficiently rare in vertex shaders that I
> don't believe there's much to be gained.

Ok.

> I believe the most valuable optimization missing from the vec4 backend
> is global copy propagation (it currently only has local copy
> propagation). *Lots* of shaders would benefit from this even before we
> switched to NIR, and even more after.
> 
> While both fs/vec4 backends have opt_copy_propagate(), the fs
> backend's implementation is much better. It first performs local (that
> is, on each basic block separately) copy propagation. Second, it uses
> the values available at the end of each block to generate an analysis
> of the dataflow, and finally it reruns local copy propagation but this
> time with more data available.
> 
> I would expect big improvements in the vec4 backend from making its
> copy propagation pass global.

I will be working on global copy propagation then.