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 B518A385703C for ; Fri, 11 Sep 2020 14:17:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B518A385703C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 08BEGNNj008122; Fri, 11 Sep 2020 09:16:24 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 08BEGNPJ008121; Fri, 11 Sep 2020 09:16:23 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 11 Sep 2020 09:16:23 -0500 From: Segher Boessenkool To: Richard Biener Cc: Aaron Sawdey , gcc-patches , Jakub Jelinek , Bill Schmidt Subject: Re: [PATCH] [PATCH] PR rtl-optimization/96791 Check precision of partial modes Message-ID: <20200911141623.GA28786@gate.crashing.org> References: <20200909182723.46246-1-acsawdey@linux.ibm.com> <20200910151006.GH28786@gate.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=-7.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 11 Sep 2020 14:17:26 -0000 On Fri, Sep 11, 2020 at 08:07:39AM +0200, Richard Biener wrote: > On Thu, Sep 10, 2020 at 5:12 PM Segher Boessenkool > wrote: > > On Thu, Sep 10, 2020 at 04:33:30PM +0200, Richard Biener wrote: > > > On Thu, Sep 10, 2020 at 4:22 PM Aaron Sawdey wrote: > > > > If it feels like a hack, that would because it is a hack. > > > > > > > > What I’d really like to discuss is how to accomplish the real goal: keep anything from trying to do other operations (zero/sign extend for one) to POImode. > > > > > > > > Is there an existing mechanism for this? > > > > > > Not that I know, but somehow x86 gets away with OImode and XImode without > > > providing too many patterns for those. > > > > What we were seeing is DSE (of all things!) tries to extract a DImode > > from a POImode (and expects that insn to exist!) That is no good. > > Maybe. I don't know what kind of operations have to exist if a mode > is present and what not. > But are you sure this will be the only case you'll run into? No, I am not sure if there are bugs related to this elsewhere in the compiler :-) Until 2014 (and documented just days ago ;-) ) all bits of a partial integer mode were considered unknown. I have looked at a lot of it in our code the past weeks, and we still treat it like that in most places. We now see bootstrap problems if we use POImode in some contexts (that's this PR96791). POImode can only live in pairs of VSX registers; taking a subreg of POImode that would not be valid on one VSX register is not okay. Maybe we are missing some hooks or macros? Segher