From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 9FC1F386F477 for ; Fri, 29 May 2020 16:57:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9FC1F386F477 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 445241045; Fri, 29 May 2020 09:57:15 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7A2103F52E; Fri, 29 May 2020 09:57:14 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Richard Biener , Martin =?utf-8?Q?Li=C5=A1ka?= , GCC Patches , richard.sandiford@arm.com Cc: Richard Biener , Martin =?utf-8?Q?Li?= =?utf-8?Q?=C5=A1ka?= , GCC Patches Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. References: <542a2fb9-e282-0614-8586-6690c627a4cd@suse.cz> <20200521201654.GX31009@gate.crashing.org> <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> Date: Fri, 29 May 2020 17:57:13 +0100 In-Reply-To: <20200529153933.GW31009@gate.crashing.org> (Segher Boessenkool's message of "Fri, 29 May 2020 10:39:33 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 16:57:18 -0000 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...). >>=20 >> 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: =E2=80=A6 For **certain** named patterns, it may invoke @code{FAIL} to t= ell the compiler to use an alternate way of performing that task. =E2=80=A6 (my emphasis). Later on they say: @findex FAIL @item FAIL =E2=80=A6 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.) Richard