From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41689 invoked by alias); 10 Jan 2019 19:06:42 -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 41675 invoked by uid 89); 10 Jan 2019 19:06:41 -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=akrl@sdf.org, akrlsdforg, U*akrl, D*sdf.org 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 ol.sdf.org (HELO mx.sdf.org) (205.166.94.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 19:06:39 +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 x0AJ6TAn007074 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 10 Jan 2019 19:06:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sdf.org; s=default; t=1547147197; bh=Dqj9AFblxouzyYYv2kO1Xa70dUDlSJ+9SrnZOdJ6ISc=; h=From:To:Cc:Subject:In-Reply-To:Date; b=EvKXC+zu2rDbJMiaW08AzyYM6cEafHaWzRPE1Y1OXIIFFZWlZ0Wl/3X2UXtRj54cO BIxmqTwQ/pNOMOjP+6q7x63iLDuZeQclnEgbQM/S+eg4fkGv2FtnAMYKzofT4GVYKs FqS6o775hQalKNz4tgF7KhHMQ0rwr5aVp53hID4I= Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x0AJ6Sua020585; Thu, 10 Jan 2019 19:06:29 GMT From: akrl To: Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= Cc: dmalcolm@redhat.com, basile@starynkevitch.net, jit@gcc.gnu.org Subject: Re: about header file parsing In-Reply-To: (message from Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= on Thu, 10 Jan 2019 19:23:15 +0100) Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00035.txt.bz2 Marc Nieper-Wi=C3=9Fkirchen writes: > [...] > >> > 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 > Hi, today I've wrote a patch that adds GCC_JIT_STR_NEEDED_LIBRARIES to gcc_jit_str_option. This was to specify a space separated list of the libraries to link against. I was going to submit the patch for review but this solution seams to be more general. If we agree on an interface I propose my self to do the patch in order to have the occasion to setup the whole process. Bests Andrea --=20 akrl@sdf.org