On Thu, Jun 18, 2015 at 12:42 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott <cwabbo...@gmail.com> wrote: >>>>> (really I want phi's for variables too.. the way I turn arrays into >>>>> fanin/collect fanout/split works on the backend for dealing with >>>>> arrays in ssa form (other than making instruction graph large) but the >>>>> way I go from nir to ir3 currently assumes I get nir phi's everywhere >>>>> I need an ir3 phi) >>>> >>>> Right... we explicitly decided not to support SSA form for arrays in >>>> NIR, since it seemed like a pretty bad idea. SSA form assumes that >>>> inserting copies for the things you're SSA-ifying is relatively >>>> inexpensive, and both SSA-based register allocation and algorithms for >>>> converting out of SSA make no guarantees about not inserting >>>> potentially unnecessary copies. This is a good compromise for smaller >>>> things, but not for your array of (say) 64 things where inserting an >>>> extra copy is rather disastrous. You can do it if you want and shoot >>>> yourself in the foot, but NIR isn't going to help you there -- we >>>> won't write a to-SSA pass for something which doesn't make much sense >>>> in the first place. >>>> >>> >>> in ir3 my solution is to add sufficient dependencies between >>> instructions so the array accesses don't get re-ordered and they all >>> collapse down to a single name per array element/slot >> >> It's not about getting reordered, it's about interference. The problem >> is that as soon as you do basically any optimization at all (even copy >> propagation), you can wind up with a situation where the sources and >> destination of a phi node interfere with each other and you have to >> insert extra mov's. And even if you keep everything exactly the same, >> with an SSA-based register allocator, there's always the chance that >> it'll screw up anyways and allocate something over your array and >> force you to insert a mov. You could force the array to be allocated >> to a single hardware register, but then it's not really an SSA value >> anymore -- it's a hardware register, and you can't treat it like an >> SSA value anymore in your allocator, and so adding phi nodes and >> whatnot for it in your IR doesn't make much sense. > > > But the point I'm trying to make is that I need the links from src to > dest that I get in SSA form for *scheduling* (for example, to know how > many delay slots are needed between two instructions). For things > like if/else, I would need to consider number of cycles since either > possible assigner. For everything else, the phi nodes (in ir3, not in > nir) give me this. Arrays are not special (since they are allocated > in registers) when it comes to cycle counts.
(or rather, instructions that write to arrays are not special...) > > BR, > -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
