client data for GCCJIT objects?

client data for GCCJIT objects?

[Basile Starynkevitch]

Hello All,

It would be nice if some client data could be attached to each GCCJIT object.

Or at least, within libgccjit++.h, to be able to use gccjit::object as
some key either for std::map or for std::unordered_map (so either an
ordered relation on their internal address, or an equality test with
some hashing). Then a user compilation context could associate
application data with GCCJIT objects. This is quite useful: an
application JIT translating some bytecode or AST would keep an
association between GCCJIT objects and application values (think of
s-exprs for GUILE) and create GCCJIT objects only if none is
associated to some application value...

In C, on could dream of a function giving, from some GCCJIT object,
its unique index in the "recording" class.

// get the object of some given index in the context
gcc_jit_object* gcc_jit_get_object_from_index(gcc_jit_context* ctx, unsigned index);

// get the positive index of some object, or 0 if NULL is given
unsigned gcc_jit_object_index(gcc_jit_object*obj);

I would be very happy to have dynamic upcasts, e.g.

// check that an object is a field, otherwise return NULL
gcc_jit_field* gcc_jit_object_to_field(gcc_jit_object* obj);


Comments are welcome. I could supply a patch if explained how to do such things...

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net   mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: client data for GCCJIT objects?

[David Malcolm]

On Tue, 2015-10-13 at 15:32 +0200, Basile Starynkevitch wrote:
> Hello All,
> 
> It would be nice if some client data could be attached to each GCCJIT object.
> 
> Or at least, within libgccjit++.h, to be able to use gccjit::object as
> some key either for std::map or for std::unordered_map (so either an
> ordered relation on their internal address, or an equality test with
> some hashing). Then a user compilation context could associate
> application data with GCCJIT objects. This is quite useful: an
> application JIT translating some bytecode or AST would keep an
> association between GCCJIT objects and application values (think of
> s-exprs for GUILE) and create GCCJIT objects only if none is
> associated to some application value...

It's possible to do this without adding additional data to the jit
object, by using the pointers of the gcc_jit_object: maintain a mapping
from gcc_jit_object * to the client data of interest.

The gcc_jit_object * will uniquely identify the object (until its
context is released, at which point the pointers become invalid and
could be reused by a different context).

> In C, on could dream of a function giving, from some GCCJIT object,
> its unique index in the "recording" class.
> 
> // get the object of some given index in the context
> gcc_jit_object* gcc_jit_get_object_from_index(gcc_jit_context* ctx, unsigned index);
> 
> // get the positive index of some object, or 0 if NULL is given
> unsigned gcc_jit_object_index(gcc_jit_object*obj);

There is indeed such an index, but I don't think it's a useful concept,
and would be confusing to the user to expose.  For example, if the
client code has nested contexts, both parent and child contexts would
typically each have their own idea about which object is at index 0.

Hopefully this isn't needed, and you can use the pointer idea above.

> I would be very happy to have dynamic upcasts, e.g.
> 
> // check that an object is a field, otherwise return NULL
> gcc_jit_field* gcc_jit_object_to_field(gcc_jit_object* obj);

That seems to me like a separate idea.  Why do you need dynamic upcasts?
I'm guessing that you mean to go from client data to get a
gcc_jit_object * (based on the remarks above), but can't you infer from
the type of the client data what kind of gcc_jit_object you have?

Hope this is helpful
Dave