On Apr 30, 2015 10:05 PM, "Connor Abbott" <cwabbo...@gmail.com> wrote:
>
> >> > 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.
Right... Yeah, assertions sound better if that's what we want to do.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
