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 7E45E39874CD for ; Fri, 29 May 2020 17:09:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7E45E39874CD 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 04TH9afB021358; Fri, 29 May 2020 12:09:36 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 04TH9aUY021351; Fri, 29 May 2020 12:09:36 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 29 May 2020 12:09:36 -0500 From: Segher Boessenkool To: Richard Biener , Martin =?utf-8?B?TGnFoWth?= , GCC Patches , richard.sandiford@arm.com Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. Message-ID: <20200529170936.GY31009@gate.crashing.org> References: <1125c547-9245-12de-6c49-fa31361b359c@suse.cz> <5F0F38D2-DC37-4B67-8F48-C4C2FCC7D4CC@gmail.com> <3f84124b-f77e-1f8e-68d1-f0a7892d07b0@suse.cz> <20200529153933.GW31009@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=-12.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, 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, 29 May 2020 17:09:40 -0000 On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote: > >> Now it looks like that those verification also simply checks optab > >> availability only but then this is just a preexisting issue (and we can > >> possibly build a testcase that FAILs RTL expansion for power...). > >> > >> So given that this means the latent bug in the powerpc backend > >> should be fixed and we should use a direct internal function instead? > > > > I don't see what you consider a bug in the backend here? The expansion > > FAILs, and it is explicitly allowed to do that. > > Well, the docs say: > > … For **certain** named patterns, it may invoke @code{FAIL} to tell the > compiler to use an alternate way of performing that task. … > > (my emphasis). Later on they say: > > @findex FAIL > @item FAIL > … > > Failure is currently supported only for binary (addition, multiplication, > shifting, etc.) and bit-field (@code{extv}, @code{extzv}, and @code{insv}) > operations. > > which explicitly says that vcond* isn't allowed to fail. > > OK, so that list looks out of date. But still. :-) > > We now explicitly say that some patterns aren't allowed to FAIL, > which I guess gives the (implicit) impression that all the others can. > But that wasn't the intention. The lines were just added for emphasis. > (AFAIK 7f9844caf1ebd513 was the first patch to do this.) Most patterns *do* FAIL on some target. We cannot rewind time. Segher