From patchwork Thu Feb 15 07:29:24 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1899189 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LK1xFYLr; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Tb6D25XNvz23hM for ; Thu, 15 Feb 2024 18:30:25 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7CBE33861849 for ; Thu, 15 Feb 2024 07:30:21 +0000 (GMT) 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 214183861818 for ; Thu, 15 Feb 2024 07:30:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 214183861818 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 214183861818 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=1707982205; cv=none; b=IrAyAY+gofXgPcoKrMI28Hp/nac1OqwDtNf09TMucdoZ8qk3ZVcxdxLrAOqvMiVUM7Kw2RgpUFg8IkReUomTjQCKO/KtAQLonxiXZEXs7xttKEs/Q49+jCFWWKSnP0+onRBOSeb03LssnXwzuzVaZqm5GQ8CThElGeVr1mI4IRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707982205; c=relaxed/simple; bh=EX00y9CCaDqOG9z1qJqjfp9j1ucxLqDvC5S8cNY3LlA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=IWGkpxZHa+LrjwczmJG/a5esDiOb3V/l8rJpn9l27O8IZ+CxAa4whrpm/FSdoZbgxOlPWepMZsh85T7LFfzJP20RGYqyDeBmsYbmhidMfTCqtyUK9nDTs8UJ4u5fL2JkNn1JL6So/YPCq4rMMGRaj/Eq5+ik4SKOt3rOkCTETYw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707982202; 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; bh=28tbuMDdKgQQbp+VRHuPqQZY/y0fuu3K74wc/0fPh1Y=; b=LK1xFYLrJKSJZ+Lb5uEpBReTaC3CrdDEvb2om2dZ63EweIvYAGPqBoBS1vsrfBMQv9hPr/ sVGIasRD1QgL7UAGbJG1k+o+bVvjNrMCqjXECogPpvCSqNFMi9CIktKrrv4Iaui6WrTPlQ l8bsYqC4IEsQdi0DNiO1CHc/Jaj2TKs= 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-643-HxCAwdIvOh6hClS8VPrmjw-1; Thu, 15 Feb 2024 02:29:29 -0500 X-MC-Unique: HxCAwdIvOh6hClS8VPrmjw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 44407101FA2A; Thu, 15 Feb 2024 07:29:29 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F240B40C9444; Thu, 15 Feb 2024 07:29:28 +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 41F7TPLR1207418 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 15 Feb 2024 08:29:26 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41F7TOTZ1207417; Thu, 15 Feb 2024 08:29:24 +0100 Date: Thu, 15 Feb 2024 08:29:24 +0100 From: Jakub Jelinek To: Richard Biener , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.8 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, T_SCC_BODY_TEXT_LINE 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Hi! AFAIK we have no code in LTO streaming to stream out or in SSA_NAME_{RANGE,PTR}_INFO, so LTO effectively throws it all away and let vrp1 and alias analysis after IPA recompute that. There is just one spot, for IPA VRP and IPA bit CCP we save/restore ranges and set SSA_NAME_{PTR,RANGE}_INFO e.g. on parameters depending on what we saved and propagated, but that is after streaming in bodies for the post IPA optimizations. Now, without LTO SSA_NAME_{RANGE,PTR}_INFO is already computed from earlier in many cases (er.g. evrp and early alias analysis but other spots too), but IPA ICF is ignoring the ranges and points-to details when comparing the bodies. I think ignoring that is just fine, that is effectively what we do for LTO where we throw that information away before the analysis, and not ignoring it could lead to fewer ICF merging possibilities. So, the following patch instead verifies that for LTO SSA_NAME_{PTR,RANGE}_INFO just isn't there on SSA_NAMEs in functions into which other functions have been ICFed, and for non-LTO throws that information away (which matches the LTO behavior). Another possibility would be to remember the SSA_NAME <-> SSA_NAME mapping vector (just one of the 2) on successful sem_function::equals on the sem_function which is not the chosen leader (e.g. how SSA_NAMEs in the leader map to SSA_NAMEs in the other function) and use that vector to union the ranges in sem_function::merge. I can implement that for comparison, but wanted to post this first if there is an agreement on doing that or if Honza thinks we should take SSA_NAME_{RANGE,PTR}_INFO into account. I think we can compare SSA_NAME_RANGE_INFO, but have no idea how to try to compare points to info. And I think it will result in less effective ICF for non-LTO vs. LTO unnecessarily. Bootstrapped/regtested on x86_64-linux and i686-linux. 2024-02-15 Jakub Jelinek PR middle-end/113907 * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged functions. * gcc.dg/pr113907.c: New test. Jakub --- gcc/ipa-icf.cc.jj 2024-02-14 14:26:11.101933914 +0100 +++ gcc/ipa-icf.cc 2024-02-14 16:49:35.141518117 +0100 @@ -3396,6 +3397,7 @@ sem_item_optimizer::merge_classes (unsig continue; sem_item *source = c->members[0]; + bool this_merged_p = false; if (DECL_NAME (source->decl) && MAIN_NAME_P (DECL_NAME (source->decl))) @@ -3443,7 +3445,7 @@ sem_item_optimizer::merge_classes (unsig if (dbg_cnt (merged_ipa_icf)) { bool merged = source->merge (alias); - merged_p |= merged; + this_merged_p |= merged; if (merged && alias->type == VAR) { @@ -3452,6 +3454,35 @@ sem_item_optimizer::merge_classes (unsig } } } + + merged_p |= this_merged_p; + if (this_merged_p + && source->type == FUNC + && (!flag_wpa || flag_checking)) + { + unsigned i; + tree name; + FOR_EACH_SSA_NAME (i, name, DECL_STRUCT_FUNCTION (source->decl)) + { + /* We need to either merge or reset SSA_NAME_*_INFO. + For merging we don't preserve the mapping between + original and alias SSA_NAMEs from successful equals + calls. */ + if (POINTER_TYPE_P (TREE_TYPE (name))) + { + if (SSA_NAME_PTR_INFO (name)) + { + gcc_checking_assert (!flag_wpa); + SSA_NAME_PTR_INFO (name) = NULL; + } + } + else if (SSA_NAME_RANGE_INFO (name)) + { + gcc_checking_assert (!flag_wpa); + SSA_NAME_RANGE_INFO (name) = NULL; + } + } + } } if (!m_merged_variables.is_empty ()) --- gcc/testsuite/gcc.dg/pr113907.c.jj 2024-02-14 16:13:48.486555159 +0100 +++ gcc/testsuite/gcc.dg/pr113907.c 2024-02-14 16:13:29.198825045 +0100 @@ -0,0 +1,49 @@ +/* PR middle-end/113907 */ +/* { dg-do run } */ +/* { dg-options "-O2" } */ +/* { dg-additional-options "-minline-all-stringops" { target i?86-*-* x86_64-*-* } } */ + +static inline int +foo (int len, void *indata, void *outdata) +{ + if (len < 0 || (len & 7) != 0) + return 0; + if (len != 0 && indata != outdata) + __builtin_memcpy (outdata, indata, len); + return len; +} + +static inline int +bar (int len, void *indata, void *outdata) +{ + if (len < 0 || (len & 1) != 0) + return 0; + if (len != 0 && indata != outdata) + __builtin_memcpy (outdata, indata, len); + return len; +} + +int (*volatile p1) (int, void *, void *) = foo; +int (*volatile p2) (int, void *, void *) = bar; + +__attribute__((noipa)) int +baz (int len, void *indata, void *outdata) +{ + if ((len & 6) != 0) + bar (len, indata, outdata); + else + foo (len, indata, outdata); +} + +struct S { char buf[64]; } s __attribute__((aligned (8))); + +int +main () +{ + for (int i = 0; i < 64; ++i) + s.buf[i] = ' ' + i; + p2 (2, s.buf, s.buf + 33); + for (int i = 0; i < 64; ++i) + if (s.buf[i] != ' ' + ((i >= 33 && i < 35) ? i - 33 : i)) + __builtin_abort (); +}