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 759F038708F0 for ; Fri, 29 May 2020 17:30:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 759F038708F0 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 04THU3h5022399; Fri, 29 May 2020 12:30:03 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 04THU3do022398; Fri, 29 May 2020 12:30:03 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 29 May 2020 12:30:03 -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: <20200529173003.GZ31009@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> <20200529164706.GX31009@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=-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:30:07 -0000 On Fri, May 29, 2020 at 06:05:14PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote: > >> Segher - do you actually know this code to guess why the patterns are defensive? > > > > Yes. > > In that case, can you give a specific example in which the patterns do > actually fail? That is a very different question. (And this is shifting the burden of proof again.) > I think Richard's point is that even the current compiler will ICE if > the vcond* patterns fail. All Martin's patch did was expose that via > the extra static checking we get for directly-mapped internal fns. How will they ICE? > If you want us to fix that by providing a fallback, we need to know what > the fallback should do. Just whatever vcond* is documented to do, of course ;-) > E.g. the obvious thing would be to emit the > embedded comparison separately and then emit bitwise operations to > implement the select. But in the powerpc case, it's actually the > comparison that's the potential problem, so that expansion would just > kick the can further down the road. > > So which vector comparisons doesn't powerpc support, and what should the > fallback vcond* expansion for them be? It depends on which set of vector registers is in use, and on the ISA version as well, what the hardware can do. What the backend can do -- well, it is allowed to FAIL these patterns, and it sometimes does. That's the whole point isn't it? vec_cmp* won't FAIL. I don't know if there is a portable variant of this? Segher