From patchwork Tue Feb 28 08:02:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 65723 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AA5043858C2B for ; Tue, 28 Feb 2023 08:02:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA5043858C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677571379; bh=V4uOr1Iu3OmYpBBOVy01pj7jmo/djcOhLAzlxzOR5c4=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=AY/QeAT0JZTsIWe0WoWon77DL6PC7GtTP3HGbm0OCyC/b59tPfJDRF3ankMsussmB nVA12TWQkXXBe+9t/hABtgCz0BT2bOoikhYIRoyGYgimlk8Mgjx+SHCYPHBaGurSQ8 ITSi0ZRLX4dCZzAa+FnT8lfDjtBO51dHiCQtTJPw= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 819E43858D39 for ; Tue, 28 Feb 2023 08:02:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 819E43858D39 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-222-FUsSIYm4OHaFJlUdz9Q3zw-1; Tue, 28 Feb 2023 03:02:13 -0500 X-MC-Unique: FUsSIYm4OHaFJlUdz9Q3zw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C685F85CBE5; Tue, 28 Feb 2023 08:02:12 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.101]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E315422A9; Tue, 28 Feb 2023 08:02:12 +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 31S82AjH1108195 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 28 Feb 2023 09:02:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31S829cU1108194; Tue, 28 Feb 2023 09:02:09 +0100 Date: Tue, 28 Feb 2023 09:02:09 +0100 To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] lto: Fix up lto_fixup_prevailing_type [PR108910] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.3 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_H2, 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 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-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained inside of build_{pointer,reference}_type_for_mode and those routines ensure that the pointer/reference type added to the chain is really unqualified (including address space), without extra user alignment and has just one entry for each of the TYPE_MODE/TYPE_REF_CAN_ALIAS_ALL pair (unless something would modify the types in place, but that would be wrong). Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but doesn't guarantee that. The testcase in the PR (which I'm not including for testsuite because when (I hope) the aarch64 backend bug will be fixed, the testcase would work either way) shows a case where user has TYPE_USER_ALIGN type with very high alignment, as there aren't enough pointers to float in the code left that one becomes the prevailing one, lto_fixup_prevailing_type puts it into the TYPE_POINTER_TO chain of float and later on during expansion of __builtin_cexpif expander uses build_pointer_type (float_type_node) to emit a sincosf call and instead of getting a normal pointer type gets this non-standard one. The following patch fixes that by not adding into those chains qualified or user aligned types and by making sure that some type for the TYPE_MODE/TYPE_REF_CAN_ALIAS_ALL combination (e.g. from lto1 initialization) isn't there already before adding a new one. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-02-28 Jakub Jelinek PR target/108910 * lto-common.cc (lto_fixup_prevailing_type): Don't add t to TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has non-zero TYPE_QUALS, or TYPE_USER_ALIGN or some other type with the same TYPE_MODE and TYPE_REF_CAN_ALIAS_ALL flag is already present. Jakub --- gcc/lto/lto-common.cc.jj 2023-01-16 11:52:16.165732856 +0100 +++ gcc/lto/lto-common.cc 2023-02-28 01:42:51.006764018 +0100 @@ -984,21 +984,35 @@ lto_fixup_prevailing_type (tree t) TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (mv); TYPE_NEXT_VARIANT (mv) = t; } - - /* The following reconstructs the pointer chains - of the new pointed-to type if we are a main variant. We do - not stream those so they are broken before fixup. */ - if (TREE_CODE (t) == POINTER_TYPE - && TYPE_MAIN_VARIANT (t) == t) - { - TYPE_NEXT_PTR_TO (t) = TYPE_POINTER_TO (TREE_TYPE (t)); - TYPE_POINTER_TO (TREE_TYPE (t)) = t; - } - else if (TREE_CODE (t) == REFERENCE_TYPE - && TYPE_MAIN_VARIANT (t) == t) + else if (!TYPE_QUALS (t) && !TYPE_USER_ALIGN (t)) { - TYPE_NEXT_REF_TO (t) = TYPE_REFERENCE_TO (TREE_TYPE (t)); - TYPE_REFERENCE_TO (TREE_TYPE (t)) = t; + /* The following reconstructs the pointer chains + of the new pointed-to type if we are a main variant. We do + not stream those so they are broken before fixup. + Don't add it if despite being main variant it is + qualified or user aligned type. Don't add it if there + is something in the chain already. */ + tree *p = NULL; + if (TREE_CODE (t) == POINTER_TYPE) + p = &TYPE_POINTER_TO (TREE_TYPE (t)); + else if (TREE_CODE (t) == REFERENCE_TYPE) + p = &TYPE_REFERENCE_TO (TREE_TYPE (t)); + if (p) + { + tree t2; + for (t2 = *p; t2; t2 = TYPE_NEXT_PTR_TO (t2)) + if (TYPE_MODE (t2) == TYPE_MODE (t) + && TYPE_REF_CAN_ALIAS_ALL (t2) == TYPE_REF_CAN_ALIAS_ALL (t)) + break; + if (t2 == NULL_TREE) + { + if (TREE_CODE (t) == POINTER_TYPE) + TYPE_NEXT_PTR_TO (t) = *p; + else + TYPE_NEXT_REF_TO (t) = *p; + *p = t; + } + } } }