From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 4D2E1384AB58 for ; Fri, 3 May 2024 19:11:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D2E1384AB58 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4D2E1384AB58 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714763492; cv=none; b=DBkZxQ5rnYEJkIeytooHCsF8xmV6mTAnu5HsYmuhqfrQqbT/UYwfO0zrssgT2IRTiG0HXht4ZoXzFLo+jgBvUKbrFtiYY2GS3UAWjSSdUkw4/4vuBGUwIj7PNQnu69aYxx22x+xgQgfIVDh+KpayyCya4nirPqS7AXQ+PtFmabE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714763492; c=relaxed/simple; bh=CyOdy0rOXF1e0veV96kpZDkaKFOeksKIj/awUfOTN6k=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=l5H90X/wJM4/z3vJylAsqMGZUyCtFYUrN+XrnDwiRwcBqM5zAldM8RsGdrlX0xSlGXZCVL2bTIdssCELtEUjq4AkF9qExlIONlVmIwEsRyePi1vuLKpyxOUHWwBBtVUJ6sJRWaXdFTFJMPkI1qm8sFL/Ava3Gs7pP8PsD+be6sU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.221] (84-115-223-216.cable.dynamic.surfer.at [84.115.223.216]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4VWL4m2T4pz1LM0S; Fri, 3 May 2024 21:11:20 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4VWL4m2T4pz1LM0S DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1714763480; bh=Ru+D7Tc+JqXOVsu6LwtWvwAIIraVhm+Y50qOB5su1Y0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=S1jzGxJeTIGK/s85SX2JkPl/WBfVqg6rp+pI82Nc8Y8AWtqtIbrFcBqZvjRB01MIX y5xXrns5IqnyanYIOZAV0pLFv8SDS7xOdDbdpK64h4tEfSmzeAUPKMygKoeoh3k2lr wsnD9YpHG5JBEcUyRskhfrir9xFiA0lu3UOGuX44= Message-ID: <39fcac8a1c61acaaa1c80602b76f48ef73f5f885.camel@tugraz.at> Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types From: Martin Uecker To: Richard Biener Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org Date: Fri, 03 May 2024 21:11:20 +0200 In-Reply-To: <05B84303-9D17-4DAE-A9D9-A77DA3EA7878@suse.de> References: <05B84303-9D17-4DAE-A9D9-A77DA3EA7878@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_ABUSEAT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP 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: Am Freitag, dem 03.05.2024 um 20:48 +0200 schrieb Richard Biener: >=20 > > Am 03.05.2024 um 20:37 schrieb Martin Uecker : > >=20 > > =EF=BB=BFAm Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jeline= k: > > > > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote: > > > > A change that is not optimal but would avoid a lot of trouble is to > > > > only use the tag of the struct for computing a TYPE_CANONICAL, whic= h > > > > could then be set already for incomplete types and never needs to > > > > change again. We would not differentiate between different struct > > > > types with the same tag for aliasing analysis, but in most cases > > > > I would expect different structs to have a different tag. > > >=20 > > > Having incompatible types have the same TYPE_CANONICAL would lead to = wrong > > > code IMHO, while for aliasing purposes that might be conservative (th= ough > > > not sure, the alias set computation is based on what types the elemen= t have > > > etc., so if the alias set is computed for say struct S { int s; }; an= d > > > then the same alias set used for struct S { long long a; double b; un= ion { > > > short c; float d; } c; };, I think nothing good will come out of that= ), > >=20 > > The C type systems requires us to form equivalence classes though. > > For example > >=20 > > int (*r)[1]; > > int (*q)[]; > > int (*p)[3]; > >=20 > > need to be in the same equivalence class even though r and p are > > not compatible, while at the same time r and q and q and p > > are compatible. >=20 > TYPE_CANONICAL as used by the middle-end cannot express this but Hm. so how does it work now for arrays? > useless_type_conversion_p is directed and has similar behavior.=C2=A0 > Note the dual-use for TBAA and compatibility was convenient but > maybe we have to separate both since making the equivalence class > for TBAA larger is more conservative while for compatibility it=E2=80=99s > the other way around=E2=80=A6 Maybe, although I do not understand why the middle end would need precise knowledge for checking type compatibility? The FE has much stricter rules.=20 Martin >=20 > Richard=20 >=20 > >=20 > > > but middle-end also uses TYPE_CANONICAL to see if types are the same, > > > say e.g. useless_type_conversion_p says that conversions from one > > > RECORD_TYPE to a different RECORD_TYPE are useless if they have the > > > same TYPE_CANONICAL. > > > /* For aggregates we rely on TYPE_CANONICAL exclusively and require > > > explicit conversions for types involving to be structurally > > > compared types. */ > > > else if (AGGREGATE_TYPE_P (inner_type) > > > && TREE_CODE (inner_type) =3D=3D TREE_CODE (outer_type)) > > > return TYPE_CANONICAL (inner_type) > > > && TYPE_CANONICAL (inner_type) =3D=3D TYPE_CANONICAL (outer= _type); > > > So, if you have struct S { int s; } and struct S { short a, b; }; and > > > VIEW_CONVERT_EXPR between them, that VIEW_CONVERT_EXPR will be remove= d > > > as useless, etc. > >=20 > > Maybe we could limit for purposes of computing TYPE_CANONICAL of derive= d > > types, e.g. TYPE_CANONICAL of structs stays the same with the transitio= n > > from TYPE_STRUCT_EQUALITY to TYPE_CANONICAL but all the derived types > > remain stable. > >=20 > > Martin > >=20 > > >=20 > > > BTW, the idea of lazily updating TYPE_CANONICAL is basically what I'v= e > > > described as the option to update all the derived types where it woul= d > > > pretty much do that for all TYPE_STRUCTURAL_EQUALITY_P types in the > > > hash table (see if they are derived from the type in question and rec= ompute > > > the TYPE_CANONICAL after recomputing all the TYPE_CANONICAL of its ba= se > > > types), except perhaps even more costly (if the trigger would be some > > > build_array_type/build_function_type/... function is called and found > > > a cached TYPE_STRUCTURAL_EQUALITY_P type). Note also that > > > TYPE_STRUCTURAL_EQUALITY_P isn't the case just for the C23 types whic= h > > > are marked that way when incomplete and later completed, but by vario= us > > > other cases for types which will be permanently like that, so doing > > > expensive checks each time some build*_type* is called that refers > > > to those would be expensive. > > >=20 > > > Jakub > > >=20 > >=20