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 A2873386F45A for ; Thu, 28 May 2020 15:28:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2873386F45A 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 55DF830E; Thu, 28 May 2020 08:28:44 -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 8B2653F52E; Thu, 28 May 2020 08:28:43 -0700 (PDT) From: Richard Sandiford To: Martin =?utf-8?Q?Li=C5=A1ka?= Mail-Followup-To: Martin =?utf-8?Q?Li=C5=A1ka?= ,Richard Biener , Segher Boessenkool , GCC Patches , richard.sandiford@arm.com Cc: Richard Biener , Segher Boessenkool , GCC Patches Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. References: <366dfa22-58e7-e1df-62c3-cc98082a552c@suse.cz> <0e5c0fa7-9719-e3ab-b909-f1c0b052b283@suse.cz> <1470b2b0-1cc3-f408-c292-a7c95325432d@suse.cz> <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> Date: Thu, 28 May 2020 16:28:42 +0100 In-Reply-To: <3f84124b-f77e-1f8e-68d1-f0a7892d07b0@suse.cz> ("Martin \=\?utf-8\?Q\?Li\=C5\=A1ka\=22's\?\= message of "Thu, 28 May 2020 16:46:35 +0200") 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=-11.1 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: Thu, 28 May 2020 15:28:45 -0000 Martin Li=C5=A1ka writes: > Hi. > > There's a new patch that adds normal internal functions for the 4 > VCOND* functions. > > The patch that survives bootstrap and regression > tests on x86_64-linux-gnu and ppc64le-linux-gnu. I think this has the same problem as the previous one. What I meant in yesterday's message is that: expand_insn (icode, 6, ops); is simply not valid when icode is allowed to FAIL. That's true in any context, not just internal functions. If icode does FAIL, the expand_insn call will ICE: if (!maybe_expand_insn (icode, nops, ops)) gcc_unreachable (); When using optabs you either: (a) declare that the md patterns aren't allowed to FAIL. expand_insn is for this case. (b) allow the md patterns to FAIL and provide a fallback when they do. maybe_expand_insn is for this case. So if we keep IFN_VCOND, we need to use maybe_expand_insn and find some way of implementing the IFN_VCOND when the pattern FAILs. Thanks, Richard