From patchwork Thu Jan 9 12:58:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 104405 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 64E103858D33 for ; Thu, 9 Jan 2025 13:04:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64E103858D33 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=uDP0YRb0; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=i6tr0Fj7; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=uDP0YRb0; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=i6tr0Fj7 X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 35F993858D28 for ; Thu, 9 Jan 2025 12:58:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 35F993858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 35F993858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736427486; cv=none; b=v2dUR+kMYyXqY0qXmtt6RrQvZVsTi2C41QVSRFHvgjAHoc4Kv6PsqJVe7/LQBJTzSWxB907JHdQ+bqMm9/eyRCAhpYTq/aKVuJc/OIzPFa8dwlUsHjJqr9wdulg2cMQ3Ih0XMres7CeA8gZLXJmYuSVM+zBxbVOIKd+8HlLTENU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736427486; c=relaxed/simple; bh=ZPM4RFTDLRfizore9nwhVvhgQhQsk7EEhpIsZRue4XI=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:MIME-Version; b=NWtHGd9hPf3V+VwryRGo0LGBq5twSIYDSdnsvFQryyKLkS/ulFlEjCu4CAYDMavKxcfJ9BaOYlpc+l4Wca5TXwFuuX7ZiBxcV+zsH6OEUO1ObLHs7Gkoj80YVodDwmDX7ZKQCef1OETdU2TyWnu2oJNjkgWn//tspVxhBlY0Vdk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 35F993858D28 Received: from murzim.nue2.suse.org (unknown [10.168.4.243]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3709921169; Thu, 9 Jan 2025 12:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1736427485; h=from:from:reply-to:date:date:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=GfhhoJ67fbcYJ4Yj8TvHuX1lWl/I7pPwmd+CJxDQSGQ=; b=uDP0YRb0RxNiXx2zZzYnJ+5ycVwZ/hEsPgN4NdiBDqe4IM2elXma4fqfwiBRj8SJ0uM2H6 36LE6e32ERJDStGFTFwXGRB7QEz5yPYwm1KC5sgGfbQ+XSyIxxnlPC5YHKyXOSabGJtn/p muGOaEERgGr9UfmUktV9uJr9ZJwyoFU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1736427485; h=from:from:reply-to:date:date:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=GfhhoJ67fbcYJ4Yj8TvHuX1lWl/I7pPwmd+CJxDQSGQ=; b=i6tr0Fj7ZgQw+zdGJQDAFdVJrxrP+4phKb2scd+IDTf8tgwuc7SkljsWVqJr1ru0w6NbSK 6Tu6OmKddpTvyOBQ== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1736427485; h=from:from:reply-to:date:date:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=GfhhoJ67fbcYJ4Yj8TvHuX1lWl/I7pPwmd+CJxDQSGQ=; b=uDP0YRb0RxNiXx2zZzYnJ+5ycVwZ/hEsPgN4NdiBDqe4IM2elXma4fqfwiBRj8SJ0uM2H6 36LE6e32ERJDStGFTFwXGRB7QEz5yPYwm1KC5sgGfbQ+XSyIxxnlPC5YHKyXOSabGJtn/p muGOaEERgGr9UfmUktV9uJr9ZJwyoFU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1736427485; h=from:from:reply-to:date:date:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=GfhhoJ67fbcYJ4Yj8TvHuX1lWl/I7pPwmd+CJxDQSGQ=; b=i6tr0Fj7ZgQw+zdGJQDAFdVJrxrP+4phKb2scd+IDTf8tgwuc7SkljsWVqJr1ru0w6NbSK 6Tu6OmKddpTvyOBQ== Date: Thu, 9 Jan 2025 13:58:05 +0100 (CET) From: Richard Biener To: gcc-patches@gcc.gnu.org cc: lhyatt@gmail.com Subject: [PATCH] Avoid PHI node re-allocation in loop copying MIME-Version: 1.0 X-Spam-Level: X-Spamd-Result: default: False [-1.37 / 50.00]; BAYES_HAM(-3.00)[99.99%]; MISSING_MID(2.50)[]; NEURAL_HAM_LONG(-0.60)[-0.597]; NEURAL_HAM_SHORT(-0.17)[-0.860]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+] X-Spam-Score: -1.37 X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, MISSING_MID, SPF_HELO_NONE, SPF_PASS, 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~patchwork=sourceware.org@gcc.gnu.org Message-Id: <20250109130443.64E103858D33@sourceware.org> duplicate_loop_body_to_header_edge redirects the original loop entry edge to the loop copy header and the copied loop exit to the old loop header. But it does so in the order that requires temporary space for an extra edge on the original loop header, causing unnecessary re-allocations. The following avoids this by swapping the order of the redirects. Bootstrapped and tested on x86_64-unknown-linux-gnu. This originally surfaced with the location_t work which effectively changed PHI allocations and thus made some passes unexpectedly get their PHI nodes re-allocated when calling loop_version. Mitigation for this was provided which might or might not be completely resolved by this (the vectorizer change is, as far as my testing goes). Pushed to trunk. I don't plan to revert the location_t changes in this area though, not at this stage at least. Richard. * cfgloopmanip.cc (duplicate_loop_body_to_header_edge): When copying to the header edge first redirect the entry to the new loop and then the exit to the old to avoid PHI node re-allocation. --- gcc/cfgloopmanip.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cfgloopmanip.cc b/gcc/cfgloopmanip.cc index 534e556e1e4..17bcf9f4acc 100644 --- a/gcc/cfgloopmanip.cc +++ b/gcc/cfgloopmanip.cc @@ -1447,9 +1447,9 @@ duplicate_loop_body_to_header_edge (class loop *loop, edge e, } else { + redirect_edge_and_branch_force (e, new_bbs[0]); redirect_edge_and_branch_force (new_spec_edges[SE_LATCH], loop->header); - redirect_edge_and_branch_force (e, new_bbs[0]); set_immediate_dominator (CDI_DOMINATORS, new_bbs[0], e->src); e = new_spec_edges[SE_LATCH]; }