On Fri, Jul 04, 2014 at 09:43:08PM -0700, Matt Turner wrote: > On Wed, Jul 2, 2014 at 6:59 AM, Pohjolainen, Topi > <topi.pohjolai...@intel.com> wrote: > > On Mon, Jun 30, 2014 at 02:40:42PM -0700, Matt Turner wrote: > >> With a hack to place an exec_node in the struct in C to be at the same > >> location as the inherited exec_node in C++. > > > > Are you planning to eventually have one but not the other? > > I'd kind of like to transition to embedding the exec_node, rather than > inheriting so that we can use the types from C. > > For this series, I don't even use .link from backend_instruction. I > just need to add exec_node to backend_instruction so that it has the > same structure in C as C++ (and I can access some of the fields from > C). > > > If this is just > > temporary it does not make a lot difference but otherwise I would rather > > have these with different names. > > I'm not sure what you mean.
My misunderstanding, I thought you weren't thinking of accessing the same data from both C and ++. I was actually curious how does this look like with gdb. We now have two different types with the same name (one in C namespace and another in C++), right? Most of the time the type is clear in the context but what if one needs to manually cast a pointer - which type (C or C++) does gdb use? > > > How big a task would it be to teach plusplus logic to use the C-type? > > I don't think it should be too difficult to switch, now that it's easy > to find the uses of the foreach* macros that cast to fs_inst or > vec4_instruction. That might actually let us do things like putting > instructions in multiple lists (one giant list, and a per-basic block > list). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
