[Mesa-dev] [PATCH 1/3] nir/register: Add a parent_instr field

[Connor Abbott]

On Tue, Feb 17, 2015 at 6:44 PM, Eric Anholt <eric at anholt.net> wrote:
> Connor Abbott <cwabbott0 at gmail.com> writes:
>
>> On Tue, Feb 17, 2015 at 3:52 PM, Eric Anholt <eric at anholt.net> wrote:
>>> Matt Turner <mattst88 at gmail.com> writes:
>>>
>>>> From: Jason Ekstrand <jason at jlekstrand.net>
>>>>
>>>> This adds a parent_instr field similar to the one for ssa_def.  The
>>>> difference here is that the parent_instr field on a nir_register can be
>>>> NULL if the register does not have a unique definition or if that
>>>> definition does not dominate all its uses.  We set this field in the
>>>> out-of-SSA pass so that backends can get SSA-like information even after
>>>> they have gone out of SSA.
>>>
>>> This will be useful for me, too, for similar multi-step multiply code.
>>
>> Wait, I thought you were translating SSA NIR to your IR, no? If so,
>> this isn't too useful.
>
> I'm calling out-of-ssa in NIR currently, not that it's really required,
> since my IR is trivially SSA due to lack of control flow and there are
> no phi nodes in the NIR.  My theory is that I'll be able to extend NIR
> to lower to the control flow primitives present in my hardware and
> adreno (which is to say, like brc/brd on ivb, but without the hardware
> per-channel execution masking), in which case I'll definitely be out of
> SSA in NIR before going into vc4.

Well, this is really off-topic but... I think you can still do the
stuff you mentioned (sort of fake handling of branches, where you can
only do uniform control flow, correct?) without going out of SSA.
Handling actual predication does get more complicated -- the essence
is that you need to create conditional select similar to what you're
doing now, but then try and push the predicate for the csel into the
instructions that define the conditions of the csel, and then use
something called "predicate analysis" to figure out when two registers
don't actually interfere because the predicate on the definition of
one is disjoint with the predicate on the use of another (i.e. the
predicates are never both true). It might be worth it for the gains
you get in the ability to do optimizations and whatnot, though.