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 942E43858D28 for ; Wed, 29 Dec 2021 16:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 942E43858D28 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 3D72B6D; Wed, 29 Dec 2021 08:54:11 -0800 (PST) Received: from localhost (unknown [10.32.98.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9F80C3F774; Wed, 29 Dec 2021 08:54:10 -0800 (PST) From: Richard Sandiford To: "Andre Vieira \(lists\)" Mail-Followup-To: "Andre Vieira \(lists\)" , "Andre Vieira \(lists\) via Gcc-patches" , Richard Biener , richard.sandiford@arm.com Cc: "Andre Vieira \(lists\) via Gcc-patches" , Richard Biener Subject: Re: [AArch64] Enable generation of FRINTNZ instructions References: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> <70s9nn94-452-5rrr-4458-q6n3qp563652@fhfr.qr> <36e3469a-3922-d49e-4006-0088eac29157@arm.com> <653o8886-3p5n-sr82-9n83-71q33o8824@fhfr.qr> <6c730f35-10b1-2843-cffc-4ed0851380be@arm.com> <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> <8d593d5f-41a0-6051-0ce0-d72834ecfa25@arm.com> <9d3755df-6c41-20e4-31fb-811e5cd9182a@arm.com> Date: Wed, 29 Dec 2021 16:54:09 +0000 In-Reply-To: <9d3755df-6c41-20e4-31fb-811e5cd9182a@arm.com> (Andre Vieira's message of "Wed, 29 Dec 2021 15:55:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Wed, 29 Dec 2021 16:54:13 -0000 "Andre Vieira (lists)" writes: > On 17/12/2021 12:44, Richard Sandiford wrote: >> >>> @@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo, >>> rhs_type =3D unsigned_type_node; >>> } >>>=20=20=20 >>> - int mask_opno =3D -1; >>> + /* The argument that is not of the same type as the others. */ >>> + int diff_opno =3D -1; >>> + bool masked =3D false; >>> if (internal_fn_p (cfn)) >>> - mask_opno =3D internal_fn_mask_index (as_internal_fn (cfn)); >>> + { >>> + if (cfn =3D=3D CFN_FTRUNC_INT) >>> + /* For FTRUNC this represents the argument that carries the type of t= he >>> + intermediate signed integer. */ >>> + diff_opno =3D 1; >>> + else >>> + { >>> + /* For masked operations this represents the argument that carries = the >>> + mask. */ >>> + diff_opno =3D internal_fn_mask_index (as_internal_fn (cfn)); >>> + masked =3D diff_opno >=3D 0; >>> + } >>> + } >> I think it would be cleaner not to process argument 1 at all for >> CFN_FTRUNC_INT. There's no particular need to vectorise it. > > I agree with this,=C2=A0 will change the loop to continue for argument 1 = when=20 > dealing with non-masked CFN's. > >>> } >>> [=E2=80=A6] >>> diff --git a/gcc/tree.c b/gcc/tree.c >>> index 845228a055b2cfac0c9ca8c0cda1b9df4b0095c6..f1e9a1eb48769cb11aa6973= 0e2480ed5522f78c1 100644 >>> --- a/gcc/tree.c >>> +++ b/gcc/tree.c >>> @@ -6645,11 +6645,11 @@ valid_constant_size_p (const_tree size, cst_siz= e_error *perr /* =3D NULL */) >>> return true; >>> } >>>=20=20=20 >>> -/* Return the precision of the type, or for a complex or vector type t= he >>> - precision of the type of its elements. */ >>> +/* Return the type, or for a complex or vector type the type of its >>> + elements. */ >>>=20=20=20 >>> -unsigned int >>> -element_precision (const_tree type) >>> +tree >>> +element_type (const_tree type) >>> { >>> if (!TYPE_P (type)) >>> type =3D TREE_TYPE (type); >>> @@ -6657,7 +6657,16 @@ element_precision (const_tree type) >>> if (code =3D=3D COMPLEX_TYPE || code =3D=3D VECTOR_TYPE) >>> type =3D TREE_TYPE (type); >>>=20=20=20 >>> - return TYPE_PRECISION (type); >>> + return (tree) type; >> I think we should stick a const_cast in element_precision and make >> element_type take a plain =E2=80=9Ctype=E2=80=9D. As it stands element_= type is an >> implicit const_cast for many cases. >> >> Thanks, > Was just curious about something here, I thought the purpose of having=20 > element_precision (before) and element_type (now) take a const_tree as=20 > an argument was to make it clear we aren't changing the input type. I=20 > understand that as it stands element_type could be an implicit=20 > const_cast (which I should be using rather than the '(tree)' cast), but=20 > that's only if 'type' is a type that isn't complex/vector, either way,=20 > we are conforming to the promise that we aren't changing the incoming=20 > type, what the caller then does with the result is up to them no? > > I don't mind making the changes, just trying to understand the reasoning= =20 > behind it. The problem with the above is that functions like the following become well-typed: void foo (const_tree t) { TYPE_MODE (element_type (t)) =3D VOIDmode; } even though element_type (t) could well be t. One of the points of const_tree (and const pointer targets in general) is to use the type system to enforce the promise that the value isn't changed. I guess the above is similar to the traditional problem with functions like index and strstr, which take a const char * but return a char *. So for example: void foo (const char *x) { index (x, '.') =3D 0; } is well-typed. But the equivalent C++ code (using iterators) would be rejected. If C allowed overloading them the correct prototypes would be: const char *index (const char *, int); char *index (char *, int); And I think the same applies here. Either we should provide two functions: const_tree element_type (const_tree); tree element_type (tree); or just the latter. Thanks, Richard