From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A0D7C384AB58 for ; Fri, 3 May 2024 18:19:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A0D7C384AB58 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A0D7C384AB58 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714760348; cv=none; b=iteJ4seUuMk2yfO2vyfiSmzk7Ql+fMyZ9l0JfUeMBK9sQfUNYQudZcPKQYrtvy/xh8pCCXP368B0Bj19Wq/5c3ufM8f2FB7tFO7gQ+a7kenUUkp/uWcKRvFUkY2ATYz7aJC00lPWuMleu6YTfrErwdLSU+VTyhErWTazDPThDsE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714760348; c=relaxed/simple; bh=4LzJHuRX68Nx9RqDSiqKeWNbbMIt5VatMMqvjKCRSd8=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=xBk9Pe7/0duWibqBsWLAcV45fPkRh1E2DGC54ZI6pHUP17xiRbRgUvqz71W6KChKqL1fjMUkkaIQfu9E6hRKjWDxQ1uVwaJDnynMRay6kA1eFK58LCVXLPk7KhW0eVMJDEpN0YTRChrBJxwYD6YuqE2jwE3iZlDySeX7u5y+sQM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714760346; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=ydKcPMO9v9+zsJa7WtZUkamGfjGAcBekRTn8mWHatoQ=; b=ZPeQOTEo28bdRLjTZ5n4X8EGvzqZDjARUAOTN5OHHNxx4tlS2KCaefn8ZchaRAtTFVRPPS 0reweHOvSasT9tA81b7AVF2WnzHm/+hsIjTemMgocJbaK9i4amVL3UKS3EYNBOxX5RSmWp OMs28bRktmOz3F4F1+EZoHehJKB8vZ8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-97-8jQDmZBtOdimmhLT0B79Hw-1; Fri, 03 May 2024 14:19:02 -0400 X-MC-Unique: 8jQDmZBtOdimmhLT0B79Hw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 844F31049C94; Fri, 3 May 2024 18:19:02 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 41763112131D; Fri, 3 May 2024 18:19:02 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 443IJ0LF3198256 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 3 May 2024 20:19:00 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 443IJ00K3198255; Fri, 3 May 2024 20:19:00 +0200 Date: Fri, 3 May 2024 20:18:59 +0200 From: Jakub Jelinek To: Martin Uecker Cc: Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types Message-ID: Reply-To: Jakub Jelinek References: <20240503121400.C8A4313991@imap1.dmz-prg2.suse.org> <3616afcc455c1f80e2bb8a80a408994a67062d85.camel@tugraz.at> <06a98adaf345a1e942a4973546ea15373adb5df5.camel@tugraz.at> MIME-Version: 1.0 In-Reply-To: <06a98adaf345a1e942a4973546ea15373adb5df5.camel@tugraz.at> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. Having incompatible types have the same TYPE_CANONICAL would lead to wrong code IMHO, while for aliasing purposes that might be conservative (though not sure, the alias set computation is based on what types the element have 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), 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) == TREE_CODE (outer_type)) return TYPE_CANONICAL (inner_type) && TYPE_CANONICAL (inner_type) == 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 removed as useless, etc. 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 recompute 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. Jakub