Antía Puentes <apuen...@igalia.com> writes: > On lun, 2015-10-12 at 15:55 +0300, Francisco Jerez wrote: >> Antía Puentes <apuen...@igalia.com> writes: >> > On dom, 2015-10-11 at 10:35 -0700, Matt Turner wrote: >> >> 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. >> > >> >> Heh... I suggest you hold yourself from working on this for a while. >> >> While working on some fragment discard improvements last week I noticed >> that a seemingly harmless change in the CFG could cause shitloads of >> shader-db regressions (>8k). The reason is that a bunch of optimization >> passes of the compiler back-end are fully local (including VEC4 copy >> propagation) and become ineffective anytime your dataflow happens to >> traverse edges of the CFG. >> >> Instead of reimplementing the intricate dataflow propagation logic (e.g. >> what fs_copy_prop_dataflow does) in every pass (or rather every pass >> that needs to consider two or more instructions at once), I've given a >> shot at implementing use-def chains in the back-end (didn't have a >> bigger hammer at hand). Use-def chains should simplify this sort of >> optimization passes massively and allow them to work globally without >> any additional effort: Instead of looping back the instruction list to >> find out whether the last instruction that wrote a register had some >> specific form (c.f. cmod_propagation, saturate_propagation, >> compute_to_mrf, which are all local and have O(n^2) complexity), you >> just look-up the use entry for the instruction you're interested in and >> look at its immediate neighbours in the use-def graph, which represent >> the instruction(s) that generated the variable. >> >> Use-def chains can be implemented trivially on an SSA IR so as an added >> benefit it should become easier to port optimization passes to SSA once >> they've been rewritten in terms of use-def chains. >> >> I've got an algorithm to construct the use-def graph basically working >> on the FS back-end (I'm not sharing it publicly yet though because in >> its current form it would likely offend some people's sensibilities -- I >> could send you a branch in private though if you're interested). I >> haven't started porting other optimization passes to use it yet, but >> it's next on my to-do list. > > Hi Francisco, > > that sounds great. Do you intend to do the same for vec4? Otherwise, I > can try to port your work to vec4 once you are done with FS.
Pretty much the whole use-def analysis logic is independent from the back-end, so it should be straightforward to port to VEC4. However I might need some help at some point rewriting other optimization passes in terms of use-def chains instead of their current hand-rolled dataflow analysis -- I'll get back to you once I have something solid for you to use as starting point. ;)
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev