[Mesa-dev] [PATCH 11/13] i965: Make backend_instruction usable from C.

Pohjolainen, Topi topi.pohjolainen at intel.com
Mon Jul 7 09:45:52 PDT 2014

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.pohjolainen at 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).

More information about the mesa-dev mailing list