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 E94923858D20 for ; Fri, 4 Feb 2022 01:25:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E94923858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 2141OB2n028470; Thu, 3 Feb 2022 19:24:11 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2141OAF3028465; Thu, 3 Feb 2022 19:24:10 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 3 Feb 2022 19:24:10 -0600 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com Subject: Re: [PATCH v3 1/8] rs6000: More factoring of overload processing Message-ID: <20220204012410.GC614@gate.crashing.org> References: <9ee506e947ec49973f757ea4a967574ded4ed2b0.1643390744.git.wschmidt@linux.ibm.com> <20220128191110.GG614@gate.crashing.org> <1d7fa906-bf3a-36bc-eeee-3c1eebb078e1@linux.ibm.com> <20220201214836.GV614@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=-3.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 04 Feb 2022 01:25:14 -0000 Hi! On Thu, Feb 03, 2022 at 08:44:48AM -0600, Bill Schmidt wrote: > Although the previous patch was correct, the logic around what to do when > the number of arguments is wrong was still hard to understand. It should > be better now. I'm now explicitly counting the number of expected arguments > and comparing against that. The way the argument list is represented ensures > there is always at least one element in the argument chain, by terminating > the chain with an argument type of void, which is why the previous logic was > so convoluted. Aha :-) > + /* Count the number of expected arguments. */ > + unsigned expected_args = 0; > + for (tree chain = fnargs; > + chain && !VOID_TYPE_P (TREE_VALUE (chain)); > + chain = TREE_CHAIN (chain)) > + expected_args++; FOREACH_FUNCTION_ARGS? > + So even though __builtin_vec_splats accepts all vector types, the > + infrastructure cheats and just records one prototype. We end up getting > + an error message that refers to this specific prototype even when we > + are handling a different argument type. That is completely confusing > + to the user, so it's best to let these cases be handled individually > + in the resolve_vec_splats, etc., helper functions. */ > + > + if (n != expected_args > + && !(fcode == RS6000_OVLD_VEC_PROMOTE > + || fcode == RS6000_OVLD_VEC_SPLATS > + || fcode == RS6000_OVLD_VEC_EXTRACT > + || fcode == RS6000_OVLD_VEC_INSERT > + || fcode == RS6000_OVLD_VEC_STEP)) > return NULL; Even I can understand that! Thank you! :-) Okay for trunk. Segher