From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E289A385DC31 for ; Thu, 10 Sep 2020 22:50:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E289A385DC31 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-535-uLH-3evVMGauxamSCkJO9Q-1; Thu, 10 Sep 2020 18:50:48 -0400 X-MC-Unique: uLH-3evVMGauxamSCkJO9Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 601391084C89; Thu, 10 Sep 2020 22:50:47 +0000 (UTC) Received: from ovpn-114-91.phx2.redhat.com (ovpn-114-91.phx2.redhat.com [10.3.114.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA97A19C66; Thu, 10 Sep 2020 22:50:46 +0000 (UTC) Message-ID: <8cb4c85a1be4fb76a80fd9666a73c82efa16ee20.camel@redhat.com> Subject: Re: libgccjit questions From: David Malcolm To: Andrea Corallo , Daurnimator Cc: jit@gcc.gnu.org Date: Thu, 10 Sep 2020 18:50:46 -0400 In-Reply-To: References: User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, 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: Thu, 10 Sep 2020 22:50:57 -0000 On Wed, 2020-09-09 at 10:18 +0200, Andrea Corallo wrote: > Daurnimator writes: > > > Hi, > > Hi! Hi! > > I'm looking into using libgccjit as an ahead-of-time compiler to > > write > > a backend for zig (https://ziglang.org/) > > I've got a few questions I hope you can answer: > > > > What became of cross-compilation? I saw it mentioned as a possible > > roadmap item in > > https://gcc.gnu.org/legacy-ml/jit/2015-q3/msg00086.html) > > AFAIK cross compilation is not supported and nothing is going on in > that > sense. I believe this is in line with the idea of libgccjit being > mainly intended for making jitters. I think it would be possible to do ahead-of-time cross-compilation with libgccjit, but I can think of some issues. 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, and most of my cycles these days are on the static analyzer feature I added in GCC 10. 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). 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). (I'm not personally very familiar with building cross toolchains; help with that would be appreciated if we pursue this idea) > > 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. > > 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. > > > Alteratively, would it be possible to get a pointer and length to > > e.g. > > an ELF 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 > Most distros are already packing libgccjit, even if the quality of > the > package may vary. > > > 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. Thanks Andrea for your responses. I hope mine are also helpful. Dave