From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 3B24B3858D28 for ; Mon, 24 Apr 2023 09:45:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3B24B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 33O9iiIW020335; Mon, 24 Apr 2023 04:44:44 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 33O9ii4c020318; Mon, 24 Apr 2023 04:44:44 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 24 Apr 2023 04:44:44 -0500 From: Segher Boessenkool To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Turn on LRA on all targets Message-ID: <20230424094444.GN19790@gate.crashing.org> References: <283c45ca085ced958cbce6e64331252c83a5899f.1682268126.git.segher@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Apr 24, 2023 at 10:19:23AM +0200, Richard Biener wrote: > On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool > wrote: > > > > This minimal patch enables LRA for all targets. It does not clean up > > the target code, nor does it do anything to generic code: it just > > deletes all target definitions of TARGET_LRA_P. > > > > There are three kinds of changes: > > > > 1) Targets that already always have LRA, but that redefine the hook > > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing > > really changes for these targets with this patch (but later patches > > will delete the superfluous hook implementations). > > 2) Targets that have LRA selectable. Some of those are probably fine, > > since they default to using LRA (arc, mips, s390). Two others don't > > though, maybe because there are problems (ft32 and sh). I'd love to > > hear from all targets in this category what the status is, how easy it > > was to convert, etc. (Note I misqualified a bunch under 1) that should be 2)). > I think 1) and 2) where the default is LRA already should be changed to > use the existing default and the ability to switch back to reload removed. > That could be done independently and soon. Sure. Those categories of backends are easy to handle anyway. Cat. 3 is the problematic category. > > 3) Targets that as of yet never used LRA. Many of those will be fine, > > but some others will need a little tuning, and a few might need some > > actual improvements to LRA itself. These are cris, epiphany, fr30, > > frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze, > > mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll > > find out how many of those targets are ever tested, and how many of > > those work with LRA without further changes, and how well. > > > > I send this patch now so that people can start testing. I don't plan to > > commit this for another week at least, for a week after GCC 13 release I > > guess? How does that plan sound to people? > > I think it's important to check that the targets still build, including a > sensible set of their target libraries in a sensible set of their > multilib configurations so they are not completely cut off from > testing. > > "Converting" targets one-by-one this way is sensible and appreciated. Yes. I sent this all-in-one simple-to-apply simple-to-test RFC patch to try and get things moving, especially for all those targets where all previous attempts have done nothing. > > This is an RFC, so no changelog, no one can accidentally commit it :-) > > I thought about Cc:ing lots and lots of people, should I do that? > > Did we announce a cut-off for reload going away? I tried to do that in but it was decided we should not announce this in user documentation. There has been talk about this on the developer mailing lists (and elsewhere, irc for example) for ages, so it shouldn't come as a surprise to anyone. > Knowing the set of > targets that fail to "auto-convert" within the above constraint would be > nice. Yes, but the response from most of the category 3 targets has been thunderous silence :-/ I'll test how many targets fall down at my boring "build Linux" (so, the kernel, not a distro :-) ) test, already. A bit scared of doing that, but it is time I guess. > Thanks for pushing! "It's a dirty job", etc. So many ancient shortcomings of GCC cannot reasonably be solved while we still allow old reload to be used (subregs of mem anyone? But that is just one example). Let's see where this goes! Segher