From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105429 invoked by alias); 10 Jan 2019 18:23: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 105399 invoked by uid 89); 10 Jan 2019 18:23:31 -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=supplying 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-pg1-f179.google.com Received: from mail-pg1-f179.google.com (HELO mail-pg1-f179.google.com) (209.85.215.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 18:23:29 +0000 Received: by mail-pg1-f179.google.com with SMTP id v28so5149589pgk.10 for ; Thu, 10 Jan 2019 10:23:29 -0800 (PST) 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=iakqfmt/sNCimkCUsMDV2ea/sXg1BvvbMcI/CgacPo0=; b=ZnRf5OTm+0ip5mTmKm2nO/wuIdZQ8+u2EySZkzO9nhj6k2febE9a4G7Ve4B1GBUGTJ 7QoFg7qmXCSkCoFUnyYbxqs391EBRg0fgENg81QbWJERkSiNXpJfCCQkLJ05q0cVtl59 wtGrx0g+w8L5xwKWR5JfSnYNIuWtH8+9qSf+VuWop/zgGpAjH7ny/as9au5WMBmO9mdH A1q0EyAHOWdtSVlm6fJJx5Os3jJpNZ69COw5IlpDpVk7n7E6sxrflHMrwG+FD7nj0WC1 +wiEkLHPV7TUAAPhx5IIKve0wnD7htIKdStLTgdDJuaBbQ/fyWh1w304fAjCFhb7e5MP 92UQ== X-Gm-Message-State: AJcUukfo7/PfcfWqPcjK767w4DSOT+Hhc0wPKQ/0iC1QjfCRL5GkCued 3dOE1Nw/ChXRkIUPb8+PWGfWtX1RqNlke8Gvbig= X-Google-Smtp-Source: ALg8bN6QUULjpSc3r5TM2MwHzPQwtOzJmK6cvBK7TZEiyE6/AywL/JZkfgVmv+yor7YXKRhZV9fEEeB8Nthbh97FoD8= X-Received: by 2002:a62:4851:: with SMTP id v78mr11337128pfa.97.1547144608016; Thu, 10 Jan 2019 10:23:28 -0800 (PST) MIME-Version: 1.0 References: <0511991f924b445cad0467ad28fc8f45.squirrel@mx.sdf.org> <1547143680.7788.154.camel@redhat.com> In-Reply-To: <1547143680.7788.154.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/msg00033.txt.bz2 [...] > > Dave, would you agree to add a patch that reuses the command line > > options set by `gcc_jit_context_add_command_line_option' when the > > driver is invoked? > > It depends on the patch :) > > I'm not opposed on principle; gcc_jit_context_add_command_line_option > already has the caveat: > "Note that only some options are likely to be meaningful" > in the docs, and it's already something of a loophole for doing things > that I haven't though of. > > I wonder if we'd need to have some distinction between options for the > compiler vs options for the driver (maybe introduce a new entrypoint > for driver options?). IIRC cc1 will complain with a fatal error if it > gets driver-specific options. This is probably the saner approach. Having two entrypoints is definitely no less powerful than having just one. What do you think of gcc_jit_context_add_driver_option? Or, alternatively, gcc_jit_context_compile_with_options and gcc_jit_context_compile_to_file_with_options? > > In particular, one would want to be able to > > override `-fno-use-linker-plugin'. > > > > Here is a use case. Assume that jitted code wants to use > > (just to give an example). The struct obstack is opaque, and many > > "functions" are implemented as macros. To solve the issues raised in > > this thread, I would write a jit-obstack.c like the following: > > > > #include > > #include > > #include > > > > #define obstack_chunk_alloc xmalloc > > #define obstack_chunk_free free > > > > struct jit_obstack > > { > > alignas (alignof (struct obstack)) char p[sizeof (struct obstack)]; > > }; > > > > int > > jit_obstack_init (struct jit_obstack *op) __attribute__ ((visibility > > ("hidden"))) > > { > > return obstack_init ((struct obstack *) op); > > } > > ... > > > > The jitted code would then access obstacks solely through > > jit-obstack.c. By doing so, we do not have to look at the internals > > of > > (which may be different on the programmer's and the > > target > > system!) and we do not have to recreate opaque structures in a > > gcc_jit_context. > > > > However, the code will only run as fast as C directly including > > if and only if we can use link-time optimization when > > creating the jitted shared object through libgccjit. > > It sounds like you want have LTO against a "jit-obstack.so" (or > somesuch) when the driver converts jit-generated assembler to its .so Actually, I think I want to link against jit-obstack.o. Thus my earlier question, whether supplying "-fuse-linker-plugin -flto jit-obstack.o" to the driver is possible. > This sounds really interesting; I've never tried LTO with libgccjit. > It might just work, but I suspect you might run into unexpected issues > of some kind. Seems like a fun thing to experiment with. We should do as this would allow wrapper libraries like the from the example above and will solve many of the problems raised in this thread. [...] Marc