From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 472 invoked by alias); 9 Jan 2019 15:53:01 -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 452 invoked by uid 89); 9 Jan 2019 15:53:01 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.210.194, H*RU:209.85.210.194, H*i:sk:1547048, H*f:sk:1547048 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_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: mail-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 15:52:58 +0000 Received: by mail-pf1-f194.google.com with SMTP id c123so3860947pfb.0 for ; Wed, 09 Jan 2019 07:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7q1CrT0viLHUl7cwovGULiaAMVdIuf1DbxRPCevw4jg=; b=pN7r0RS3lzhRsaC0kGkmw1KrMNO8U20uQ+qmvS+uAFJsU4fNy3Kl4t4ErDTYiGK5c1 6+qX42o/OAOcQr3x76hqlXpnhJCXtrxypXqptEeUYosIUPsK/Xkl1n61N4u2RFmtDxFV nptvQCDUPM3vJ5XXFmciuGD47H6OieiGWkganNTcLeNTZthSxW6D7olzNh7O9pQqiSPd fInx+sxDK/+5SpLx/ZKaTwof1tftvwkRwVyddc6XJ+e3yyrniED5cGz5SVzWVRtil6US 8oRKD7lLjRKNMH28si85h7eCx8X/dM8u1nNnQI1lxfuoFqObV4HJ1DaSebSNVPiv8A6I q4zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7q1CrT0viLHUl7cwovGULiaAMVdIuf1DbxRPCevw4jg=; b=s4YCPtgLvCYJ3G8TKhuYgxeVTScpv1vhhTNJCRKFKRLj3pDRc/kk12EVUxnF/X1eTE IHf7qMHdEtMjdw78KytgLbv0G0dx+erizJ/rSCeivryru5xj338RQics0t5M9jPcp8it mvEkeVDKBpR3uSFPPAh65s8aQIDYWM2x48KDKWB45NKpHvBNlIUO0gXRbJltCGiylzQk Pe23jJqHvhD+TZpiP+sjaJeTBHTzm4HZWlGdZaSbR829EbEjHOi0oXmpwMFeH1G5YGbn Tpi0hEoMjA/kGS/3AiB1k2OBIED9pWscJANeyZkHKgkeObTrkUn94qgT5pNyReHHMIoW OQ1w== X-Gm-Message-State: AJcUukdDdon/HC9+l41svX2beANucJFoOSBfBdyV5Gi8F4xt11S5CKxA A/jEwhffbChFJuBApDG/FIhbCKzIitl/cfdI0ws= X-Google-Smtp-Source: ALg8bN7J4+zkoCeo5qDuCvnfu6UhGZLMMlpx0OIggPR1+oeLcqGOjMKRWsNJWD+vVfmg16NH4dcrz2OUHL9FaOQK558= X-Received: by 2002:a65:50c1:: with SMTP id s1mr5726617pgp.350.1547049176899; Wed, 09 Jan 2019 07:52:56 -0800 (PST) MIME-Version: 1.0 References: <85568212-cec8-f8c8-2941-8db5d19e2989@starynkevitch.net> <1547048594.7788.120.camel@redhat.com> In-Reply-To: <1547048594.7788.120.camel@redhat.com> From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: about header file parsing To: David Malcolm Cc: Basile Starynkevitch , akrl , jit@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00024.txt.bz2 How would you handle, for example, gmp's header file? https://gmplib.org/repo/gmp/file/default/gmp-h.in Almost all of the public API is behind #define's. So even if the gcc_jit_context is filled with the functions that are declared in the header, one still needs to know the ABI of GMP to know which functions to call. In order to make it work in the general case (if this is at all possible), I think one has to turn the C frontend of GCC into a library (like libgccjit has turned the GCC middle/backend into a library). This hypothetical library X has its own context K that is populated by expanding and parsing the relevant header files. In this context K, we can then ask for expansion of strings of C tokens (e.g. in expression or statement context). Library X then returns the expansion in term of, say, a C-specific GENERIC tree, which can then be converted into/wrapped into a gcc_jit_object. -- Marc Am Mi., 9. Jan. 2019 um 16:43 Uhr schrieb David Malcolm : > > On Wed, 2019-01-09 at 16:13 +0100, Basile Starynkevitch wrote: > > On 1/9/19 4:03 PM, akrl wrote: > > > Sorry I try to explain it better. > > > I was thinking to a gcc plugin (or potentially something else) > > > that > > > given a C file produce the libgccjit code necessary to fill a > > > context > > > with what is in the source file. > > > > That could not work in general, because C has macros (think of the > > `EOF` > > macro constant in ``) that have no equivalent in libgccjit. > > Although possibly not working "in general" I think it could work for > most important cases. A macro in C typically can be handled as either > a client-side function invocation in libgccjit, or as a libgccjit > function. > > For example, CPython has various reference-counting macros: > > #define Py_XDECREF(op) do { if ((op) == NULL) ; else Py_DECREF(op); } while (0) > > and in my "coconut" JIT-compiler for CPython I implement this as a > libgccjit function: > > https://github.com/davidmalcolm/coconut/blob/master/coconut/compiler.py > #L501 > > (effectively treating it as a static inline function). > > > And > > in practice C macros are very important (and a lot of API for C are > > using macros, see also macros such as WIFEXITED in wait(2) on some > > Linux > > system). > > > > We have to admit that C and libgccjit are different "languages" (even > > if > > conceptually very close). And a C API is not exactly a set of > > "objects" > > that libgccjit can handle. > > They're not the same, but it is important that libgccjit be able to > interoperate well with C APIs. > > Dave