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 42E96388C002 for ; Fri, 29 May 2020 15:39:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 42E96388C002 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 04TFdXVg014904; Fri, 29 May 2020 10:39:34 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 04TFdXPj014903; Fri, 29 May 2020 10:39:33 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 29 May 2020 10:39:33 -0500 From: Segher Boessenkool To: Richard Biener Cc: Martin =?utf-8?B?TGnFoWth?= , GCC Patches , Richard Sandiford Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. Message-ID: <20200529153933.GW31009@gate.crashing.org> 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> 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=-12.9 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 15:39:38 -0000 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. Not allowed to FAIL are: -- The "lanes" things; -- vec_duplicate, vec_series; -- maskload, maskstore; -- fmin, fmax; -- madd and friends; -- sqrt, rsqrt; -- fmod, remainder; -- scalb, ldexp; -- sin, cos, tan, asin, acos, atan; -- exp, expm1, exp10, exp2, log, log1p, log10, log2, logb; -- significand, pow, atan2, floor, btrunc, round, ceil, nearbyint, rint; -- copysign, xorsign; -- ffs, clrsb, clz, ctz, popcount, parity. All vcond* patterns are allowed to fail. Maybe ours don't *need* to, but that doesn't change a thing. In general, it is a Very Good Thing if patterns are allowed to fail: if they are not allowed to fail, they have to duplicate all the code that the generic expander should have, into ever target that needs it. It also makes writing a (new) backend easier. Segher