From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78784 invoked by alias); 19 Oct 2015 14:25:11 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 78770 invoked by uid 89); 19 Oct 2015 14:25:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1445264703.3998.26.camel@surprise> Subject: Re: client data for GCCJIT objects? From: David Malcolm To: Basile Starynkevitch Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <20151013133204.GA7100@ovh.starynkevitch.net> References: <20151013133204.GA7100@ovh.starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-SW-Source: 2015-q4/txt/msg00009.txt.bz2 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