On Apr 30, 2015 10:05 PM, "Connor Abbott" <<a href="mailto:cwabbott0@gmail.com">cwabbott0@gmail.com</a>> 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.