From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23509 invoked by alias); 10 Jan 2019 19:02:48 -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 23497 invoked by uid 89); 10 Jan 2019 19:02:47 -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=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no 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; Thu, 10 Jan 2019 19:02:46 +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 ED56E2DD763; Thu, 10 Jan 2019 19:02:44 +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 09C5160C67; Thu, 10 Jan 2019 19:02:43 +0000 (UTC) Message-ID: <1547146963.7788.158.camel@redhat.com> Subject: Re: about header file parsing From: David Malcolm To: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= Cc: Basile Starynkevitch , akrl , jit@gcc.gnu.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: References: <0511991f924b445cad0467ad28fc8f45.squirrel@mx.sdf.org> <1547143680.7788.154.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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.29]); Thu, 10 Jan 2019 19:02:45 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00034.txt.bz2 On Thu, 2019-01-10 at 19:23 +0100, Marc Nieper-Wißkirchen wrote: > [...] > > > > 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? I prefer gcc_jit_context_add_driver_option. > > > 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. Aha. Makes sense. I think this would be three invocations of gcc_jit_context_add_driver_option, one per option. > > 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. Indeed (assuming no unexpected snags...) Dave