From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95682 invoked by alias); 9 Jan 2019 15:27:27 -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 95662 invoked by uid 89); 9 Jan 2019 15:27:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=functional, family, interest X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 15:27:24 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 685B08AE40; Wed, 9 Jan 2019 15:27:23 +0000 (UTC) Received: from ovpn-116-42.phx2.redhat.com (ovpn-116-42.phx2.redhat.com [10.3.116.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9F4F10A1853; Wed, 9 Jan 2019 15:27:22 +0000 (UTC) Message-ID: <1547047641.7788.114.camel@redhat.com> Subject: Re: about header file parsing From: David Malcolm To: Basile Starynkevitch , akrl Cc: jit@gcc.gnu.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: <91ed8280-269a-c868-bfa4-d66607c3a3fd@starynkevitch.net> References: <91ed8280-269a-c868-bfa4-d66607c3a3fd@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 09 Jan 2019 15:27:23 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00022.txt.bz2 On Wed, 2019-01-09 at 15:04 +0100, Basile Starynkevitch wrote: > On 1/9/19 12:12 PM, akrl wrote: > > > > I think the idea of having something like a gcc plugin that once is > > parsed > > compiles the subset of supported C to the necessary libgccjit code > > would be > > useful to have for this cases but also educative for learning how > > to use the > > library. > > > > Would be this something that is upstreamable in some form? > > > > I don't know of any GCC plugin within the GCC code base (except the > test cases for plugins). I think GCC's one-year release would be too slow for such a plugin, so I think it would best to keep it out-of-tree, at least initially. > And I am not sure it would be that easy. If I understand well, > what you suggest would either fill some gcc_jit_context, or create it > already filled with an API. > > But, AFAIK, there is no current way to query the content of some > gcc_jit_context. In other words, it > seems (but I could be wrong) that what is lacking is an API to e.g. > *fetch* all the struct-ures and > all the functions inside a gcc_jit_context, and we don't have that > yet. Interesting idea, and one that somehow I didn't think of; thanks. I don't know that client code wants to fetch *all* entities; maybe we want something like: extern gcc_jit_type * gcc_jit_context_get_type_by_name (gcc_jit_context *, const char *); extern gcc_jit_field * gcc_jit_type_get_field_by_name (gcc_jit_type *, const char *); ...and so on. But I'm thinking of this from the "write a JIT for CPython" use-case, whereas IIRC you're on the functional programming side of the family. I think the above would be perfectly implementable, and probably make it much easier to implement things. I suppose we could have a: extern gcc_jit_object * gcc_jit_context_for_each_object (gcc_jit_context *, some_callback_type, void *user_data, int visit_parent_contexts); or somesuch, though I don't know if we have enough introspection in the API yet for this to be useful. > Or perhaps, I have misundertood your idea. > > My feeling was that the GCC plugin would fill whatever data structure > is used by the application using libgccjit. > And that is application specific -so the GCC plugin has to be > application specific too. I don't think it has to be; I think the plugin just needs to emit some kind of reflected representation of the IR of interest in some form that can populate a gcc_jit_context. > Cheers > > PS. I could be very wrong, it is not clear in my head! Thanks Dave