From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123130 invoked by alias); 9 Jan 2019 15:16:32 -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 122771 invoked by uid 89); 9 Jan 2019 15:15:57 -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,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=express, octave, Octave X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable 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:15:33 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6D59412F8F5; Wed, 9 Jan 2019 15:15:24 +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 0844F67146; Wed, 9 Jan 2019 15:15:23 +0000 (UTC) Message-ID: <1547046923.7788.103.camel@redhat.com> Subject: Re: about header file parsing From: David Malcolm To: akrl Cc: jit@gcc.gnu.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 09 Jan 2019 15:15:24 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00021.txt.bz2 On Wed, 2019-01-09 at 11:12 +0000, akrl wrote: > On 8 January 2019 18:21, David Malcolm wrote: > > On Tue, 2019-01-08 at 10:50 +0000, akrl@sdf.org wrote: > > Hi all, > > I have a basic question. > > Is there a way to ask libgccjit to parse a conventional .h > file? > > Sadly, no. > > > Or alternatively is there a way to have an header file parsed > and > > converted in the equivalent libgccjit api calls? > > Having a standard way to do this would be useful. > > > I ask this because I noticed that, if you jit some code that > have to > > inter-operate with non jitted code, maintaining two duplicated > > definitions > > of all data structures can be quite painful if these are not > trivial. > > I agree that this is a nuisance. > > > Alternatively what's the suggested work flow? > > One idea I came up with was to use libabigail: > https://sourceware.org/libabigail/ > to generate an ABI description e.g. via abidw: > https://sourceware.org/libabigail/manual/abidw.html > which emits an XML file, and then have a pre-canned way of > populating a > gcc_jit_context from such an abigail ABI representation. > > This code doesn't exist yet, though (but would just need writing > once). > > Dave > > > Best Regards > > Andrea > > > > 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. I really like this idea. Code using this plugin is going to want e.g. to access fields of structs, globals, etc, so it needs a way to: (a) populate a gcc_jit_context with those entities from the parsed C, (b) have a way for client code to get at those entities. As a concrete use-case, I attempted to use libgccjit to write a JIT- compiler for CPython, and found myself writing tedious error-prone code by hand to express the header: https://github.com/davidmalcolm/coconut/blob/master/coconut/compiler.py (ugh!) This client code was written in Python, using the Python bindings to libgccjit, rather than directly using the C API. So presumably the plugin ought to support writing out the representation in some simple serialized format, and have a way to get at it from the various languages that bind libgccjit. Or maybe it's simplest to start with getting at the reflected IR from C? (I'm thinking aloud here) [Ideally it would support parsing C++ also, but clearly that's some big feature-creep: I attempted to write a JIT for GNU Octave, which is implemented in C++, and ran into the same issue as above: lots of hand- written reflection of the classes and globals. Probably best to focus on a plugin for the C frontend for now.] > > Would be this something that is upstreamable in some form? Maybe eventually, but given that libgccjit is part of gcc and thus has a one-year release cycle, it feels like something that would best be a 3rd-party project for now. Any takers? (my day job is bug-fixing gcc 9 right now) Dave > Bests > > Andrea