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 09144385841B for ; Fri, 10 Sep 2021 15:06:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09144385841B 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 18AF5fsa023239; Fri, 10 Sep 2021 10:05:41 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 18AF5egi023231; Fri, 10 Sep 2021 10:05:40 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 10 Sep 2021 10:05:40 -0500 From: Segher Boessenkool To: Richard Biener Cc: Michael Meissner , GCC Patches , David Edelsohn , Bill Schmidt , Peter Bergner , Will Schmidt Subject: Re: [PATCH] Fix SFmode subreg of DImode and TImode Message-ID: <20210910150540.GW1583@gate.crashing.org> References: <20210907230730.GM1583@gate.crashing.org> <20210908170809.GP1583@gate.crashing.org> <5DBC1101-9DD6-48F8-BC25-F4DD354B4D74@gmail.com> <20210908191602.GQ1583@gate.crashing.org> <20210909234832.GU1583@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 15:06:43 -0000 On Fri, Sep 10, 2021 at 12:53:37PM +0200, Richard Biener wrote: > On Fri, Sep 10, 2021 at 1:50 AM Segher Boessenkool > wrote: > > And many targets have strange rules for bit-strings in which modes can > > be used as bit-strings in which other modes, and at what offsets in > > which registers. Now perhaps none of that is optimal (I bet it isn't), > > but changing this without a transition plan simply does not work. > > But we _do_ already allow some of them :/ Like Yes. And all of this is old and ingrained, and targets depend on the status quo, so changing this will need more care and planning and cooperation. It certainly is a worthwhile thing to improve, but it is not a small project, and it requires a plan. > /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though store_bit_field > is the culprit here, and not the backends. */ > else if (known_ge (osize, regsize) && known_ge (isize, osize)) > ; > > so for the special case where 'regsize' matches osize it would be > a bit-cast of a full register from int to float. But as written it also > allows (subreg:XF (reg:TI)) which will likely wreck havoc? That does not pass the isize >= osize test? Or maybe I don't know what XFmode is well enough :-) Hey I can read, I have source, and it is Friday... Ah. So XF has different size on 32-bit and on 64-bit, but that doesn't even matter here. > Similar for the omode == word_mode check which allows > (subreg:DI (reg:TF ..)). That is, the existing special-cases look > too broad to me - and they probably exist because when validate_subreg > rejects sth then we can't put it together later when expand split it > into two subregs and a pseudo ... I said it before, and I'll say it again, it is a very important point: expand should not try to optimise this, *at all*. And not just this, not *anything*. Expand's job in the current compiler is only to translate Gimple to RTL, and nothing more. When later passes try to optimise things they will always ask the target if it agrees with the change (all RTL has to pass recog() for example). This simplifies life. Segher