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 2B2BA3858433 for ; Mon, 15 May 2023 11:10:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B2BA3858433 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 8956D2F4; Mon, 15 May 2023 04:11:35 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29DF33F7BD; Mon, 15 May 2023 04:10:50 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,"Andre Vieira \(lists\)" , Richard Biener , "gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: "Andre Vieira \(lists\)" , Richard Biener , "gcc-patches\@gcc.gnu.org" Subject: Re: [PATCH 2/3] Refactor widen_plus as internal_fn References: <51ce8969-3130-452e-092e-f9d91eff2dad@arm.com> <4df83136-82f9-de0b-7e66-007b9047174d@arm.com> Date: Mon, 15 May 2023 12:10:48 +0100 In-Reply-To: (Richard Biener's message of "Mon, 15 May 2023 11:01:14 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-23.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Biener writes: > On Mon, 15 May 2023, Richard Sandiford wrote: > >> Richard Biener writes: >> > But I'm also not sure >> > how much of that is really needed (it seems to be tied around >> > optimizing optabs space?) >> >> Not sure what you mean by "this". Optabs space shouldn't be a problem >> though. The optab encoding gives us a full int to play with, and it >> could easily go up to 64 bits if necessary/convenient. >> >> At least on the internal-fn.* side, the aim is really just to establish >> a regular structure, so that we don't have arbitrary differences between >> different widening operations, or too much cut-&-paste. > > Hmm, I'm looking at the need for the std::map and > internal_fn_hilo_keys_array and internal_fn_hilo_values_array. > The vectorizer pieces contain > > + if (code.is_fn_code ()) > + { > + internal_fn ifn = as_internal_fn ((combined_fn) code); > + gcc_assert (decomposes_to_hilo_fn_p (ifn)); > + > + internal_fn lo, hi; > + lookup_hilo_internal_fn (ifn, &lo, &hi); > + *code1 = as_combined_fn (lo); > + *code2 = as_combined_fn (hi); > + optab1 = lookup_hilo_ifn_optab (lo, !TYPE_UNSIGNED (vectype)); > + optab2 = lookup_hilo_ifn_optab (hi, !TYPE_UNSIGNED (vectype)); > > so that tries to automatically associate the scalar widening IFN > with the set(s) of IFN pairs we can split to. But then this > list should be static and there's no need to create a std::map? > Maybe gencfn-macros.cc can be enhanced to output these static > cases? Or the vectorizer could (as it did previously) simply > open-code the handled cases (I guess since we deal with two > cases only now I'd prefer that). Ah, yeah, I pushed back against that too. I think it should be possible to do it using the preprocessor, if the macros are defined appropriately. But if it isn't possible to do it with macros then I agree that a generator would be better than initialisation within the compiler. Thanks, Richard