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 6949D384AB58 for ; Fri, 3 May 2024 18:37:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6949D384AB58 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 6949D384AB58 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=1714761446; cv=none; b=rsLMWJ975xEBp6b7Vo3axbgvfpKSMRYrnydf+Ye1AoxD9dySb3gTOdttpOgy2jb4D5aBG5qE7rGbOUV+7n1WqQfVV5IeTN9M8SjelBnMCl+UWrhTjVqiZ3TqidD0hWw2BykmKvmZH02sU1Q7HyRHxU7kM0GcgUFoB7E3bt1/EQA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714761446; c=relaxed/simple; bh=MXvxCs/bnODpHgltYRPmo3ZpwSP8DI5IG3HF9f+/TKc=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=VbXqbzyXfHGcyHSAYF+1K3qwgCHmQ+A5gwF1OxQxME9nxKL+XssefdYAFeOc6fzaY50F1RFLWFEQl4+nWa6wKQnkVx+2bLknhkOVZldQWvXrXMvDWrDSlc4x3z8j1pdxlpB6d51XBz9oOlJLXMsROgjH3PBtRrMpzBCGPIwGtyA= 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 4VWKKY4FLLz3wVq; Fri, 3 May 2024 20:37:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1714761441; bh=HgiH6JxV9dNSVEGGatAkLIx8gVwKk0p32PVEkouwyYk=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=XZRoasFUhH2uOpZbzW4tAnRP46l6RTPDu335hEziPc/elhgppsCiM60aFz4QiOhf4 G3KRNHAaXkCAX+BNCKCtHH6njJdFxgjBoJ/wgnhzWG6FuSF3m04gitPiABM0lo+da0 NdVXviZsUH8Ucm0nCUoQG9M6Kn9jshlSVQQpajBk= Message-ID: Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types From: Martin Uecker To: Jakub Jelinek Cc: Richard Biener , gcc-patches@gcc.gnu.org Date: Fri, 03 May 2024 20:37:20 +0200 In-Reply-To: References: <20240503121400.C8A4313991@imap1.dmz-prg2.suse.org> <3616afcc455c1f80e2bb8a80a408994a67062d85.camel@tugraz.at> <06a98adaf345a1e942a4973546ea15373adb5df5.camel@tugraz.at> 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=-2.0 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:18 +0200 schrieb Jakub Jelinek: > 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, which > > 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 wron= g > code IMHO, while for aliasing purposes that might be conservative (though > not sure, the alias set computation is based on what types the element ha= ve > etc., so if the alias set is computed for say struct S { int s; }; and > then the same alias set used for struct S { long long a; double b; union = { > short c; float d; } c; };, I think nothing good will come out of that), The C type systems requires us to form equivalence classes though. For example int (*r)[1]; int (*q)[]; int (*p)[3]; need to be in the same equivalence class even though r and p are=20 not compatible, while at the same time r and q and q and p are compatible. > 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_ty= pe); > 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 removed > as useless, etc. Maybe we could limit for purposes of computing TYPE_CANONICAL of derived types, e.g. TYPE_CANONICAL of structs stays the same with the transition from TYPE_STRUCT_EQUALITY to TYPE_CANONICAL but all the derived types remain stable. Martin >=20 > BTW, the idea of lazily updating TYPE_CANONICAL is basically what I've > described as the option to update all the derived types where it would > 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 recompu= te > the TYPE_CANONICAL after recomputing all the TYPE_CANONICAL of its base > 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 which > are marked that way when incomplete and later completed, but by various > 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