From patchwork Tue Oct 1 10:00:06 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 1991383 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=D0+4NPvF; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; 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 [8.43.85.97]) (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 4XHtkF1qvHz1xsq for ; Tue, 1 Oct 2024 20:01:09 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6D2563875DE7 for ; Tue, 1 Oct 2024 10:01:07 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id DDDB53875442 for ; Tue, 1 Oct 2024 10:00:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDDB53875442 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DDDB53875442 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727776846; cv=none; b=HK9XvlEEyP/IiFn5N/luH+9SvYReUFGBz8npQZTmF7hM2lhxehz/y027aLcH2dEDx+JlQ6T2yMpSTltFl0x7Ufu6j6c5ctgrcnw6Ok1u31fvhVcfsWt+6CBgTVQ1s67eHxuxw2Oti/hrzj8lAUjlSjko+KhQqRrxI2Iu4iHCadE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727776846; c=relaxed/simple; bh=d7gZgIXa+gCFqHc4Boj4lMNiWsQMcgkaJUGeUOAfhwM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=M2oJbEPaKosjnD3FWqYezYQckOC7FruNOJwnSpUo6pcFSyiF+Z/4r91hWvnRuHMQXlkCXHx1ip4N2j7V/kO/3xnxyJ80iOAKVLkWczo32gtnMYVlhGIzpwfHP+WKz7gYArfqH4x8JDLp9kOrESJUxnQn6PeKDbVv5cpmZqwP/bw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5398e33155fso3216007e87.3 for ; Tue, 01 Oct 2024 03:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1727776842; x=1728381642; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=Y8tn8bif6qMIhWQcONHVnTM78Cpniv151+kn8ct/Rl4=; b=D0+4NPvFHHEfEUm4ZGwwhzSQu0Q9JsIJPi7ten1LJT+6Hh/xVR2ZQkPnGvuSKjXHn0 VuopC5/haAiHkBSHSziEmzos35uSV3/zcnxVYeF0a+YU/w1lyEdB5TT2Gu7VeWARV7Dx lowWIdw4uQvHQGR8UzSEERSSCMLC763gvzEr1CQWBODOaWRKVLAx9c87SVaxUaK+gsyx rFgF8ASHe57EdpXj6cddgaeesZW8jNOhdqHQZNAD/r/ogiH/8ugW2t4FIc//TVi35Bi6 DeYLdEnHwJNqq8WlhlBjy3z6vUGVKYEctnSdd/w1OqZ8r3Sf4ml2NlBSM1btrKbXiYBU kHQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727776842; x=1728381642; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y8tn8bif6qMIhWQcONHVnTM78Cpniv151+kn8ct/Rl4=; b=oPGY3bbYWGR5tqKa53AgqP4koszNDjh48Twhimcn0GxG40LJyW2cGiEj2why62TSRj B6ZNeGi2CLu/FRD67YiFc+d2H6eY7450RA9cmzrDxCB59tSS+VHSNu0TeaVCQC19qzZ/ DOD72qZPOXK2MoZyEfe0Jspv6gQGdMuJ039gJfIsw+1joJNT6vn30WlWlrMJeqiwNseg y0wI2NrWM7rxd8qwMfQ7U1Wmspdu3nrgTDl9lnr15MFJU6iXgRDZhQ7BvXRcAfKdXgTE OI8bJRdoSzqKdF6+J5cVTx5LCzwSwqtD3yO/yEYiOmAytJg/EO0hsxDwnXPCnsDZnys0 hBmg== X-Gm-Message-State: AOJu0Yy48ateHcuYeNFsS8+8TMAzvYiEJ2kqhRtVjxb3kCVi//cx4OOD 29z8rAPzvORQLFzLyUBUQRwQgw2cdgVczQnO8G1d1yROsXzKQ3ANXazI8J8ubgs7hWborfXKQUA = X-Google-Smtp-Source: AGHT+IGVxmq6ui1fPHkFX2HdLL8VNeNi1mjiwvxwqNp2gDlyHzRE5sq4lnuG5X6Hlb0DLb+wBGtPRQ== X-Received: by 2002:a05:6512:33d6:b0:539:958f:1b84 with SMTP id 2adb3069b0e04-539958f1c7dmr3336651e87.17.1727776841778; Tue, 01 Oct 2024 03:00:41 -0700 (PDT) Received: from fomalhaut.localnet ([2a01:e0a:8d5:d990:e654:e8ff:fe8f:2ce6]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42f57e30374sm130022325e9.42.2024.10.01.03.00.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2024 03:00:40 -0700 (PDT) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix wrong code out of NRV + RSO + inlining (take 2) Date: Tue, 01 Oct 2024 12:00:06 +0200 Message-ID: <5613124.rdbgypaU67@fomalhaut> MIME-Version: 1.0 X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, 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~incoming=patchwork.ozlabs.org@gcc.gnu.org Hi, the attached Ada testcase compiled with -O -flto exhibits a wrong code issue when the 3 optimizations NRV + RSO + inlining are applied to the same call: if the LHS of the call is marked write-only before inlining, then it will keep the mark after inlining although it may be read in GIMPLE from that point on. The proposed fix is to apply the removal of the store that would have been applied by execute_fixup_cfg if the call was not inlined: /* For calls we can simply remove LHS when it is known to be write-only. */ if (is_gimple_call (stmt) && gimple_get_lhs (stmt)) { tree lhs = get_base_address (gimple_get_lhs (stmt)); if (VAR_P (lhs) && (TREE_STATIC (lhs) || DECL_EXTERNAL (lhs)) && varpool_node::get (lhs)->writeonly) { gimple_call_set_lhs (stmt, NULL); update_stmt (stmt); todo |= TODO_update_ssa | TODO_cleanup_cfg; } } right before inlining, which will prevent the problematic references to the LHS from being generated during inlining. Tested on x86-64/Linux, OK for the mainline? 2024-10-01 Eric Botcazou * tree-inline.cc (expand_call_inline): Remove the store to the return slot if it is a global variable that is only written to. 2024-10-01 Eric Botcazou * gnat.dg/lto28.adb: New test. * gnat.dg/lto28_pkg1.ads: New helper. * gnat.dg/lto28_pkg2.ads: Likewise. * gnat.dg/lto28_pkg2.adb: Likewise. * gnat.dg/lto28_pkg3.ads: Likewise. diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc index f31a34ac410..8d43b033319 100644 --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -5130,9 +5130,23 @@ expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id, if (DECL_P (modify_dest)) suppress_warning (modify_dest, OPT_Wuninitialized); + /* If we have a return slot, we can assign it the result directly, + except in the case where it is a global variable that is only + written to because, the callee being permitted to read or take + the address of its DECL_RESULT, this would invalidate the flag + on the global variable; instead we preventively remove the store, + which would have happened later if the call was not inlined. */ if (gimple_call_return_slot_opt_p (call_stmt)) { - return_slot = modify_dest; + tree base = get_base_address (modify_dest); + + if (VAR_P (base) + && (TREE_STATIC (base) || DECL_EXTERNAL (base)) + && varpool_node::get (base)->writeonly) + return_slot = NULL; + else + return_slot = modify_dest; + modify_dest = NULL; } }