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 85A12385841B for ; Fri, 10 Sep 2021 15:33:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85A12385841B 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 18AFWNYJ025993; Fri, 10 Sep 2021 10:32:23 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 18AFWN1F025992; Fri, 10 Sep 2021 10:32:23 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 10 Sep 2021 10:32:23 -0500 From: Segher Boessenkool To: Hongtao Liu Cc: Richard Biener , Michael Meissner , Peter Bergner , Bill Schmidt , GCC Patches , David Edelsohn Subject: Re: [PATCH] Fix SFmode subreg of DImode and TImode Message-ID: <20210910153223.GX1583@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:33:25 -0000 On Fri, Sep 10, 2021 at 11:09:31AM +0800, Hongtao Liu wrote: > On Fri, Sep 10, 2021 at 7:49 AM Segher Boessenkool > wrote: > > way too long. But from that same history it follows that anything you > > do not super carefully (with testing everywhere) will cause some serious > Frankly, testing everywhere is too heavy a burden for developers, > after all, everyone has a limited variety of machines, and may not be > familiar with using other targets' simulators. Your change should be tested on enough relevant targets that we can have confidence it works properly. That does not necessarily mean you have to test everywhere yourself (although that is greatly appreciated, makes life easier for everyone, including yourself, and as David points out the cfarm is a great help). So you didn't realise your patch would wreak havoc on most other targets than what you tested on. It happens, it helps if you can avoid it, but you learn only from things that go wrong :-) (The patch has still not been reverted btw. I'll do this later tonight if you don't). > And back to the problem we were trying to solve at the beginning > (subreg:HF(reg:SI)), I guess this is not just a problem in x86 > backend, any backend can encounter similar problems, that's why we > remove all the weird cases in validate_subreg. Expand should simply expand to two statements: one doing the real subreg, the other doing the bit_cast. Segher