From patchwork Fri Jan 28 09:18:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 50509 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 3FF513947424 for ; Fri, 28 Jan 2022 09:18:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3FF513947424 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1643361524; bh=IyEX1NfmJDo7snyb6EGPlbqQdCdikw0ePEM6fvgq2fE=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=GSZGtALPkLwGSDsGnCit1+YKAzS9Y3HEhh+fazTEMxPeXX2FJntc8+8Rx/5GurGQ1 d7dWOBC8ZVj7R7t4zW5cT3KAw+suciBYuDdouCyg6TKDBDpl9GKGOLlAKagpFIGgr0 4CwFy7jhHxXGSaBq71jOVu3Gl9gV9jr35Xi+3VQo= 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.129.124]) by sourceware.org (Postfix) with ESMTPS id 4B7F73858D1E for ; Fri, 28 Jan 2022 09:18:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B7F73858D1E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-263-PHyiZjr3N6CaE8MoDx5DVQ-1; Fri, 28 Jan 2022 04:18:11 -0500 X-MC-Unique: PHyiZjr3N6CaE8MoDx5DVQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DB1461083F60; Fri, 28 Jan 2022 09:18:09 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 460D978C29; Fri, 28 Jan 2022 09:18:09 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20S9I6pL3385897 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 28 Jan 2022 10:18:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20S9I5vC3385896; Fri, 28 Jan 2022 10:18:05 +0100 Date: Fri, 28 Jan 2022 10:18:05 +0100 To: Richard Biener , Jeff Law Subject: [PATCH] cfgrtl: Fix up locus comparison in unique_locus_on_edge_between_p [PR104237] Message-ID: <20220128091805.GM2646553@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! The testcase in the PR (not included for the testsuite because we don't have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking, one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1 and compare that) has different code generation for -g vs. -g0. The difference appears during expansion, where we have a goto_locus that is at -O0 compared to the INSN_LOCATION of the previous and next insn across an edge. With -g0 the locations are equal and so no nop is added. With -g the locations aren't equal and so a nop is added holding that location. The reason for the different location is in the way how we stream in locations by lto1. We have lto_location_cache::apply_location_cache that is called with some set of expanded locations, qsorts them, creates location_t's for those and remembers the last expanded location. lto_location_cache::input_location_and_block when read in expanded_location is equal to the last expanded location just reuses the last location_t (or adds/changes/removes LOCATION_BLOCK in it), when it is not queues it for next apply_location_cache. Now, when streaming in -g input, we can see extra locations that don't appear with -g0, and if we are unlucky enough, those can be sorted last during apply_location_cache and affect what locations are used from the single entry cache next. In particular, second apply_location_cache with non-empty loc_cache in the testcase has 14 locations with -g0 and 16 with -g and those 2 extra ones sort both last (they are the same). The last one from -g0 then appears to be input_location_and_block sourced again, for -g0 triggers the single entry cache, while for -g it doesn't and so apply_location_cache will create for it another location_t with the same content. The following patch fixes it by comparing everything we care about the location instead (well, better in addition) to a simple location_t == location_t check. I think we don't care about the sysp flag for debug info... Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-01-28 Jakub Jelinek PR lto/104237 * cfgrtl.cc (loc_equal): New function. (unique_locus_on_edge_between_p): Use it. Jakub --- gcc/cfgrtl.cc.jj 2022-01-18 11:58:58.947991128 +0100 +++ gcc/cfgrtl.cc 2022-01-27 19:32:13.949937750 +0100 @@ -778,6 +778,29 @@ rtl_split_block (basic_block bb, void *i return new_bb; } +/* Return true if LOC1 and LOC2 are equivalent for + unique_locus_on_edge_between_p purposes. */ + +static bool +loc_equal (location_t loc1, location_t loc2) +{ + if (loc1 == loc2) + return true; + + expanded_location loce1 = expand_location (loc1); + expanded_location loce2 = expand_location (loc2); + + if (loce1.line != loce2.line + || loce1.column != loce2.column + || loce1.data != loce2.data) + return false; + if (loce1.file == loce2.file) + return true; + return (loce1.file != NULL + && loce2.file != NULL + && filename_cmp (loce1.file, loce2.file) == 0); +} + /* Return true if the single edge between blocks A and B is the only place in RTL which holds some unique locus. */ @@ -796,7 +819,7 @@ unique_locus_on_edge_between_p (basic_bl while (insn != end && (!NONDEBUG_INSN_P (insn) || !INSN_HAS_LOCATION (insn))) insn = PREV_INSN (insn); - if (insn != end && INSN_LOCATION (insn) == goto_locus) + if (insn != end && loc_equal (INSN_LOCATION (insn), goto_locus)) return false; /* Then scan block B forward. */ @@ -808,7 +831,7 @@ unique_locus_on_edge_between_p (basic_bl insn = NEXT_INSN (insn); if (insn != end && INSN_HAS_LOCATION (insn) - && INSN_LOCATION (insn) == goto_locus) + && loc_equal (INSN_LOCATION (insn), goto_locus)) return false; }