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 BBD313858401 for ; Fri, 10 Sep 2021 21:28:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BBD313858401 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 18ALRIae004595; Fri, 10 Sep 2021 16:27:18 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 18ALRH62004592; Fri, 10 Sep 2021 16:27:17 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 10 Sep 2021 16:27:16 -0500 From: Segher Boessenkool To: Richard Biener Cc: liuhongt , GCC Patches , Michael Meissner , Jim Wilson , Andreas Schwab , Andrew Waterman , asolokha@gmx.com Subject: Re: [PATCH 2/2] validate_subreg before call gen_lowpart to avoid ICE. Message-ID: <20210910212716.GC1583@gate.crashing.org> References: <20210910125818.334531-1-hongtao.liu@intel.com> <20210910125818.334531-3-hongtao.liu@intel.com> <20210910133010.GV1583@gate.crashing.org> <44C6CD6D-B9A5-4ECF-A6DE-6EFC57CD55A6@gmail.com> <20210910162450.GY1583@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 21:28:21 -0000 On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: > On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool wrote: > >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random two > >modes: such a truncation needs to have a meaning at all, for the > >question to make any sense. Maybe we can add an assert to this macro to > >root out nonsensical callers? > > > >Btw. We have > >#define TRULY_NOOP_TRUNCATION_MODES_P(MODE1, MODE2) \ > > (targetm.truly_noop_truncation (GET_MODE_PRECISION (MODE1), \ > > GET_MODE_PRECISION (MODE2))) > >which is not optimal, either: does truncating DFmode to HFmode behave > >the same as truncating DImode to HImode, on every target? On *any* > >target, even?! > > When is it for any non-scalar integral mode? I suspect this was only meaningful for integer modes from the start. On x86 i387 math any float mode truncation is noop (with not doing actual truncation to inf). And trunc on floating point modes was added later? Yeah, sounds like a good theory. So we should have an assertion in TNTMP that both modes are integral? (Scalar of course). Segher