From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 81C59385B22B; Mon, 11 Apr 2022 06:00:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 81C59385B22B Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 785EE1FD0C; Mon, 11 Apr 2022 06:00:32 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 58603A435E; Mon, 11 Apr 2022 06:00:32 +0000 (UTC) Date: Mon, 11 Apr 2022 08:00:32 +0200 (CEST) From: Richard Biener To: David Malcolm cc: Antoni Boucher , gcc-patches@gcc.gnu.org, jit@gcc.gnu.org, jakub@redhat.com Subject: Re: rustc_codegen_gcc and libgccjit for GCC 12 ? In-Reply-To: <4e768a1ee7492627c88a06c4c3d168d7dca95840.camel@redhat.com> Message-ID: <734q4116-7n53-rn2q-4s4r-o9837rq56297@fhfr.qr> References: <4e768a1ee7492627c88a06c4c3d168d7dca95840.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, PDS_OTHER_BAD_TLD, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 11 Apr 2022 06:00:36 -0000 On Fri, 8 Apr 2022, David Malcolm wrote: > I'm excited to read that rustc_codegen_gcc, the libgccjit-based backend > for rustc can now bootstrap rustc: > https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10 > > I've been focusing on the analyzer, and so haven't been as on top of > libgccjit patch review as I should have been. Sorry about that. > > rustc_codegen_gcc currently recommends that people build their own > libgccjit, as it contains a number of patches that aren't in gcc trunk > yet. > > We're deep in "stage 4" of gcc 12, but libgccjit is a relatively self- > contained part of the project, so I'm wondering if it makes sense to > try to get all/some of these patches into gcc 12. > > Antoyo: your email of: > https://gcc.gnu.org/pipermail/jit/2022q1/001475.html > said: > > [..snip...] > > > Ok, if the 4 patches currently being reviewed (and listed here: > > https://github.com/antoyo/libgccjit-patches) were included in gcc 12, > > I'd be able to build rustc_codegen_gcc with an unpatched gcc. > > > > It is to be noted however, that I'll need more patches for future > > work. > > Off the top of my head, I'll at least need a patch for the inline > > attribute, try/catch and target-specific builtins. > > The last 2 features will probably take some time to implement, so > > I'll > > let you judge if you think it's worth merging the 4 patches currently > > being reviewed for gcc 12. > > > > Are users of rustc_codegen_gcc still likely to need to build their own > libgccjit even if we got all of the following into gcc 12? If so, then > it's probably best to wait. > > > Jakub/Richi (as release managers): how would you feel about me pushing > some of these libgccjit-specific patches into trunk deep in stage 4? I > believe the risk is low, though I should note that I'm going on > vacation on 18th through 22nd April and won't have access to my > computer that week. libgccjit isn't release critical apart from build breaking things, so I'm fine with pushing extra improvements there. If needed we'll revert build breakers, possibly leaving the thing in some weird state. Richard. > > Looking at https://github.com/antoyo/libgccjit-patches I see 5 patches. > That said, all but the last one refer to .c source files and so predate > the big .c to .cc migration of the gcc source tree. So it looks like > the patches in that repo may need refreshing. > > More detailed status: > > [PATCH] Add support for sized integer types, including 128-bit integers > [PR95325] > Most recent discussion is here: > https://gcc.gnu.org/pipermail/jit/2021q2/001303.html > My notes say that I'm waiting on an updated version of patch > addressing the issues in that review. Was there one? > > > [PATCH] libgccjit: Add support for bitcasts [PR104071] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 > Most recent discussion seems to be > https://gcc.gnu.org/pipermail/jit/2022q1/001475.html > I've just now posted a review of that version; LGTM with some nits, > though it adds a trivial tree_cc_finalize which I'm strictly speaking > not a maintainer of. > > > [PATCH] libgccjit: Add support for register variables [PR104072] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 > Review thread: https://gcc.gnu.org/pipermail/jit/2022q1/001466.html > Latest patch seems to be: > https://gcc.gnu.org/pipermail/jit/2022q1/001510.html > My recollection is that the jit parts of the patch look OK, but this > adds a (trivial) new reginfo_cc_finalize which would thus need approval > from an RTL maintainer. > > > [PATCH] libgccjit: Add option to hide stderr logs [PR104073] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 > Review thread: https://gcc.gnu.org/pipermail/jit/2022q1/001469.html > Latest patch: https://gcc.gnu.org/pipermail/jit/2022q1/001480.html > I approved https://gcc.gnu.org/pipermail/jit/2022q1/001483.html > This looks ready to go, assuming release managers are happy. > > > [PATCH] libgccjit: Add support for setting the alignment [PR104293] > https://gcc.gnu.org/pipermail/jit/2022q1/001494.html > I've just now posted a review of that patch; some minor changes > needed. > > So I think I'm waiting on an updated version of the sized-integer-types > patch, and some nit-fixes for the other patches (but am disappearing on > vacation on 18th - 22nd). > > > Hope the above makes sense; sorry again for not getting to these > patches sooner. > > Dave > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)