>> > typedef struct nir_src {
>> > union {
>> > + nir_instr *parent_instr;
>> > + struct nir_if *parent_if;
>> > + };
>> > +
>> > + struct list_head use_link;
>>
>> So I was thinking about this, and I realized that putting the list
>> link here would mean that having SSA-only sources, like my experiments
>> with making derefs instructions, would be a massive pain. Making a
>> separate nir_ssa_src to put the use_link and parent_instr/parent_if in
>> seems like a lot more churn, but would it be harder/even more churn to
>> do it after this series rather than as a part of it? I don't think it
>> necessitates re-doing everything or giving up entirely, but I thought
>> it would be useful to note. I guess we could always use the full
>> nir_src and then do an assert(is_ssa) in the validator.
>
> We could also put it in nir_reg_src and nir_ssa_src. Since the list is
> embedded in a ssa value, we know what kind of source it is. It would mean
> that we would have to split up the iterators though. Not a big deal.
>
The issue is that nir_ssa_src doesn't exist -- we directly embed the
nir_ssa_def pointer in nir_src. So we would have to replace every
occurrence of foo->src[0].ssa foo[0]->src[0].ssa.def and fixup all the
function definitions, hence all the extra churn.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
