On Thu, Apr 2, 2015 at 1:24 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Thu, Apr 2, 2015 at 1:20 AM, Kenneth Graunke <kenn...@whitecape.org> wrote: >> On Wednesday, April 01, 2015 07:22:40 PM Connor Abbott wrote: >>> I think it might be better here if we had a callback that backends can >>> fill in that tells you when an instruction can be pulled out by the >>> sel peephole. As Jason noted, you won't be able to do this for >>> everything (notably, output writes and variable writes) and we'll >>> probably need special handling for predicating discards if we want to >>> be able to flatten everything. There are also a few cases where on >>> i965 we aren't activating it when we could. Even then, I didn't think >>> we'd need something this general, but with different backends with >>> such varying needs I guess it makes more sense to go with the more >>> general solution. >> >> NIR does have nir_intrinsic_discard_if, which performs a conditional >> discard. Assignments can be handled by conditional selects. In the >> absence of other memory writes (atomics, images, etc), that's probably >> sufficient, no? > > Yes, that should be sufficient assuming array accesses can be > flattened etc. However, the NIR pass shouldn't flatten things that > can't be flattened so we don't generate wrong NIR. Instead, in those > cases, we should just let the backend die on control-flow.
right.. I'll have a go at hoisting things out that can be moved (like kill -> kill_if and change writes to output to writes to var and then select before write to output).. for things that can't be moved, let the backend fail.. doubtful a backend that doesn't support flow control will support atomics and other 'fancy stuff' anyways ;-) (which.. does makes me wonder how I'll eventually deal w/ atomics vs instruction scheduling.. maybe I can split them out into a separate unconditional successor basic block since at that point I'd be doing instruction scheduling at the basic block level. I think.) BR, -R > --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
