From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37161 invoked by alias); 9 Jan 2019 17:16:05 -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 35473 invoked by uid 89); 9 Jan 2019 17:16:02 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=express, octave, Octave, suggestions X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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: mx.sdf.org Received: from mx.sdf.org (HELO mx.sdf.org) (205.166.94.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 17:15:58 +0000 Received: from sdf.org (IDENT:akrl@sverige.freeshell.org [205.166.94.5]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id x09HFp3V024376 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Wed, 9 Jan 2019 17:15:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sdf.org; s=default; t=1547054156; bh=AF6mtkOYbV4bqV8AIQtbgtdIxCGlzi08Ka9GadBcoaw=; h=From:To:Cc:Subject:In-Reply-To:Date; b=F0LGvRIX1OCAHKHxVzHMgUKqfby4nFxxuorIVSIch8jklZ5HdPE49hOsmRZpghaae HMplNdTFEA4vubhAiBNIpXJ3YRrQSKix6uelLuvUBNgoMnPZRn2VZjECURARvXTxjl H+Aop8OGNRDZ0JUjPEFy/EoQ0HkSCt7rMy19jv34= Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x09HFpiI011870; Wed, 9 Jan 2019 17:15:51 GMT From: akrl To: David Malcolm Cc: jit@gcc.gnu.org Subject: Re: about header file parsing In-Reply-To: <1547046923.7788.103.camel@redhat.com> (message from David Malcolm on Wed, 09 Jan 2019 10:15:23 -0500) Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00028.txt.bz2 David Malcolm writes: > 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) I guess would is a good point to start with. > [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 > Okay I'll try to put some mostly weekend time on it. I'll come up with something and I'll let you guys know. Feel free if you have suggestions. Bests Andrea -- akrl@sdf.org