[Mesa-dev] [PATCH] nir: add helper to get # of src/dest components

[Rob Clark]

On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott <cwabbott0 at 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.

BR,
-R