From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id E4AC53857C41 for ; Fri, 11 Sep 2020 02:42:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E4AC53857C41 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=daurnimator.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=master@daurnimator.com Received: by mail-wm1-x32b.google.com with SMTP id z9so3328087wmk.1 for ; Thu, 10 Sep 2020 19:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daurnimator.com; s=daurnimator; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eE1lZGkJ1MmhmpPqA3kw3HbJmSig6SGUJyuhTCB4vQ4=; b=rR915AcnSDcqe+FkfhytcyAXdDB8tfjVtbQHnjoszdEWoMVANU1eV1GekgBkrbfc8p 7IlBH1yY8WrAjQwsXXu3tPUJtvAFOa0AEE+a4pNObfG0wwuegj7AF7txOiIjhIyd8biB 7WMALHGqJqT5ypGXOFVyT+yss0O9fc+pGt84Y= 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=eE1lZGkJ1MmhmpPqA3kw3HbJmSig6SGUJyuhTCB4vQ4=; b=Cj0abYMxGQGS1Jgsh9yiPArU+aFQCMH9De14jjTBP8/k+MiKywuUc8zMLatUaONGWE qjyy0MNqt9uPVlAqKav3h77U99W7UavaYvuETLIfAqFV8DTMV1jvjMBawm/PuDeB1Xzb EQEE4yfWCQK0GymDCyfbQQiC/lrp/mpdq/RlnJchPOT0Jf9QHbLSVrba/qOnuYE7N+uV qU+XMOh1o3ixkVxf6C1+CR6JeCgCD9SXpWUCA8UO6dF6nvD7kz94P6HI6RfUwCfNPU4l DWGkmq1YWq8N3gwFyRVuFT3Cj9cqoJYCe+QklNbfua9CpjxSoC8kbbOQS+TlDvIe5Bce 7u9Q== X-Gm-Message-State: AOAM531vjDtUj5FGNBEFIZCaUdVKFonxtNGHYf2wyPj1MAa0ClkBvfmH Z83kDLuhds+5tWmhJ0Qi+UPLMVC/dMBlXfmtA1cDzQ== X-Google-Smtp-Source: ABdhPJxDVQupTP228GvFl9NUggQM4NdQVT4VhP3bahhssKTIWyt4/3RxIboOqpDoSlTfScIPcPt66OPM2y6XIJ2hPpo= X-Received: by 2002:a7b:cf30:: with SMTP id m16mr2882358wmg.0.1599792178963; Thu, 10 Sep 2020 19:42:58 -0700 (PDT) MIME-Version: 1.0 References: <8cb4c85a1be4fb76a80fd9666a73c82efa16ee20.camel@redhat.com> In-Reply-To: <8cb4c85a1be4fb76a80fd9666a73c82efa16ee20.camel@redhat.com> From: Daurnimator Date: Fri, 11 Sep 2020 12:42:47 +1000 Message-ID: Subject: Re: libgccjit questions To: David Malcolm Cc: Andrea Corallo , jit@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 02:43:01 -0000 On Fri, 11 Sep 2020 at 08:50, David Malcolm wrote: > When I last looked at it (years ago) I got bogged down in the question > of "which target are you compiling for?" with thoughts about being able > to support multiple targets, with different backends as DSOs loaded by > libgccjit. But that approach would involve a massive refactoring This sounds reasonable to me.... > Rethinking this, a less ambitious approach would be to simply support > configuring libgccjit for a different target with the usual --target= > param at configure time, and make it the client code's responsibility > to load the correct libgccjit.so (and there could only be one linked > into any given process). At first glance, this seems like it could be on the route to the previous idea. Conceivably you could have a sort of proxy-shared object that loads the target-specific libgccjit. I'm imagining that when you create a context you'd specify a target architecture: if the target-specific-libgccjit isn't installed then the context creation would fail. > In theory that would work, but given the non-standard way that > libgccjit integrates with the gcc driver code I'd anticipate issues > with converting the assembler code to .o and executables (you'd need > binutils configured for the relevant target also, and libgccjit would > need to be able to find it). So for inline assembly, does libgccjit call out to binutils' gas? Or is it used somehow as a library? Are other pieces of binutils actually needed? > (I'm not personally very familiar with building cross toolchains; help > with that would be appreciated if we pursue this idea) We currently link against libllvm for this and we can target any architecture we wish with the one binary/library. I'm hoping we can one day use GCC in a similar way. > > > How can I support inline assembly? > > > > I believe you cannot use inline assembly as we have no specific > > support > > for that and asm and __asm__ are not builtin functions so they can't > > be > > used with gcc_jit_context_get_builtin_function. > > I've written a mostly complete patch for inline assembly here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 > which I hope to get into the tree for GCC 11. Looks great! Will be happy to give this a try once merged/released. > > > Would it be reasonable to add an API that allows extracting > > > sections > > > without writing out to a file and reading it back in? > > > > The elf file is always produced because the assembler is invoked as a > > child process, so as of today this cannot happen in memory. > > > > > > > > Should distros be packaging libgccjit? > > > I noticed that e.g. ArchLinux is not. Possibly because it is > > > documented as "experimental"; possibly because it requires building > > > gcc with --enable-host-shared ? > > Given that we've had > 5 years of ABI-compatible releases I removed the > "alpha" warnings from https://gcc.gnu.org/wiki/JIT back in May. > > I would like distros to package it. > > Some notes on packaging are at: > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#packaging-notes What would the penalty be of always compiling with --enable-host-shared ? The docs note "slight performance hit": but is it actually significant? > > > What is the license situation with libgccjit; is it GPL? LGPL? what > > > does this mean for code that uses libgccjit? > > > > AFAIU libgccjit is part of GCC and this is released under the GNU > > General Public License. Is my understanding correct then that a zig compiler built with libgccjit support would then become GPL? (and otherwise it would be MIT licensed)