From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47369 invoked by alias); 4 Jan 2019 12:13:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 47357 invoked by uid 89); 4 Jan 2019 12:13:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*ebotcazou, sk:ebotcaz, U*ebotcazou X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Jan 2019 12:13:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6C4815AD; Fri, 4 Jan 2019 04:13:15 -0800 (PST) Received: from localhost (unknown [10.32.98.35]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 05F2D3F5D4; Fri, 4 Jan 2019 04:13:14 -0800 (PST) From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou ,, richard.sandiford@arm.com Cc: Subject: Re: [1/2] PR88598: Optimise x * { 0 or 1, 0 or 1, ... } References: <87bm4wr6ku.fsf@arm.com> <1848503.BfMgXAnLGD@polaris> Date: Fri, 04 Jan 2019 12:13:00 -0000 In-Reply-To: <1848503.BfMgXAnLGD@polaris> (Eric Botcazou's message of "Fri, 4 Jan 2019 13:04:27 +0100") Message-ID: <87o98wpqna.fsf@arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-01/txt/msg00154.txt.bz2 Eric Botcazou writes: >> Index: gcc/tree.c >> =================================================================== >> --- gcc/tree.c 2019-01-04 11:39:24.810266962 +0000 >> +++ gcc/tree.c 2019-01-04 11:40:33.141683783 +0000 >> @@ -11229,6 +11229,60 @@ initializer_zerop (const_tree init, bool >> } >> } >> >> +/* Return true if EXPR is an initializer expression that consists only >> + of INTEGER_CSTs for which IP0 or IP1 holds and REAL_CSTs for which >> + RP0 or RP1 holds. The choice between IP0 and IP1, and between >> + RP0 and RP1, can vary from one element to the next. */ >> + >> +template> + bool (*RP0) (const_tree), bool (*RP1) (const_tree)> >> +bool >> +initializer_each_a_or_bp (const_tree expr) >> +{ >> +#define RECURSE(X) initializer_each_a_or_bp (X) >> + >> + STRIP_ANY_LOCATION_WRAPPER (expr); >> + >> + switch (TREE_CODE (expr)) >> + { >> + case INTEGER_CST: >> + return IP0 (expr) || IP1 (expr); >> + >> + case REAL_CST: >> + return RP0 (expr) || RP1 (expr); >> + >> + case VECTOR_CST: >> + { >> + unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr); >> + if (VECTOR_CST_STEPPED_P (expr) >> + && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant (&nelts)) >> + return false; >> + >> + for (unsigned int i = 0; i < nelts; ++i) >> + if (!RECURSE (VECTOR_CST_ENCODED_ELT (expr, i))) >> + return false; >> + >> + return true; >> + } >> + >> + default: >> + return false; >> + } >> + >> +#undef RECURSE > > Can we avoid the gratuitous use of template here? We were told that C++ would > be used only when it makes things more straightforward and it's the contrary > in this case, to wit the need for the ugly RECURSE macro in the middle. I did it that way so that it would be easy to add things like zero_or_minus_onep without cut-&-pasting the whole structure. The way to do that in C would be to use a macro for the full function, but that's even uglier due to the extra backslashes. I can change it to: for (unsigned int i = 0; i < nelts; ++i) { tree elt = VECTOR_CST_ENCODED_ELT (expr, i); if (!initializer_each_a_or_bp (elt)) return false; } if we want to avoid macros. I was actually worried that this wouldn't be C++ enough, due to not using a function template to combine each pair of functions. :-) Richard