From patchwork Fri Sep 15 09:20:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 1834784 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org 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 4Rn7vn4GJHz1ynD for ; Fri, 15 Sep 2023 19:20:37 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6CB0B385843E for ; Fri, 15 Sep 2023 09:20:35 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id AD2873858D1E for ; Fri, 15 Sep 2023 09:20:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD2873858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-CSE-ConnectionGUID: uoYoeFSXTjat4MKDwnrs/A== X-CSE-MsgGUID: b73b6VHES0SwhhLUEk8gtA== X-IronPort-AV: E=Sophos;i="6.02,148,1688457600"; d="scan'208,223";a="19197887" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 15 Sep 2023 01:20:17 -0800 IronPort-SDR: LXDG1IT4MMEkLkpHXD1MeO3/g7lXeTKuTDdmSkcEpoTSCBvY698IXtOlDnn2GOFkqI0pJfUg39 pJdLoiF+NB416hz2/2qIM6ra0C68TENr2PL7gF4Ntl52SjaxwJ6mkY3q1rW/rVN+QEblofbINZ 7VwhE0LHkJvmlmfAeD2fuTilNhxeoSgYLytk/jMhM64bIMbcnbqJoVrq04m9LlcDpyRFbnZblP nJyV3wcfaIfX2ST6j260xH7mfEsESdY7pkeOaxeEzeT8k/6/GS5SMCFDLE2OvG5qLiTsfpcib4 j80= From: Thomas Schwinge To: Richard Biener , Jan Hubicka , CC: Tobias Burnus , Jakub Jelinek Subject: [WIP] Re-introduce 'TREE_USED' in tree streaming User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/28.2 (x86_64-pc-linux-gnu) Date: Fri, 15 Sep 2023 11:20:03 +0200 Message-ID: <87jzsryerg.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, 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 Sender: "Gcc-patches" Hi! Now, that was another quirky debug session: in 'gcc/omp-low.cc:create_omp_child_function' we clearly do set 'TREE_USED (t) = 1;' for '.omp_data_i', which ends up as formal parameter for outlined '[...]._omp_fn.[...]' functions, pointing to the "OMP blob". Yet, in offloading compilation, I only ever got '!TREE_USED' for the formal parameter '.omp_data_i'. This greatly disturbs a nvptx back end expand-time transformation that I have implemented, that's active 'if (!TREE_USED ([formal parameter]))'. After checking along all the host-side OMP handling, eventually (in hindsight: "obvious"...) I found that, "simply", we're not streaming 'TREE_USED'! With that changed (see attached "Re-introduce 'TREE_USED' in tree streaming"; no visible changes in x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu 'make check'), my issue was quickly addressed -- if not for the question *why* 'TREE_USED' isn't streamed (..., and apparently, that's a problem only for my case..?), and then I found that it's *intentionally been removed* in one-decade-old commit ee03e71d472a3f73cbc1a132a284309f36565972 (Subversion r200151) "Re-write LTO type merging again, do tree merging". At this point, I need help: is this OK to re-introduce unconditionally, or in some conditionalized form (but, "ugh..."), or be done differently altogether in the nvptx back end (is 'TREE_USED' considered "stale" at some point in the compilation pipeline?), or do we need some logic in tree stream read-in (?) to achieve the same thing that removing 'TREE_USED' streaming apparently did achieve, or yet something else? Indeed, from a quick look, most use of 'TREE_USED' seems to be "early", but I saw no reason that it couldn't be used "late", either? Original discussion "not streaming and comparing TREE_USED": "[RFC] Re-write LTO type merging again, do tree merging", continued "Re-write LTO type merging again, do tree merging". In 2013, offloading compilation was just around the corner -- "Summary of the Accelerator BOF at Cauldron" -- and you easily could've foreseen this issue, no? ;-P Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 From cba6e4a8ec3b8718de7857b90d0137ae82f381fb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 15 Sep 2023 00:14:13 +0200 Subject: [PATCH] [WIP] Re-introduce 'TREE_USED' in tree streaming I have a nvptx back end expand-time transformation implemented, that's active 'if (!TREE_USED ([formal parameter]))'. Now I found that per one-decade-old commit ee03e71d472a3f73cbc1a132a284309f36565972 (Subversion r200151) "Re-write LTO type merging again, do tree merging", 'TREE_USED' has *intentionally been removed* from tree streaming. That means, in nvptx offloading compilation, every formal parameter (like for outlined '[...]._omp_fn.[...]' functions the one that's pointing to the "OMP blob", '.omp_data_i', for example) is considered unused, and thus mis-optimized. --- gcc/tree-streamer-in.cc | 1 + gcc/tree-streamer-out.cc | 1 + 2 files changed, 2 insertions(+) diff --git a/gcc/tree-streamer-in.cc b/gcc/tree-streamer-in.cc index 5bead0c3c6a..f82374e60a5 100644 --- a/gcc/tree-streamer-in.cc +++ b/gcc/tree-streamer-in.cc @@ -132,6 +132,7 @@ unpack_ts_base_value_fields (struct bitpack_d *bp, tree expr) TYPE_ARTIFICIAL (expr) = (unsigned) bp_unpack_value (bp, 1); else TREE_NO_WARNING (expr) = (unsigned) bp_unpack_value (bp, 1); + TREE_USED (expr) = (unsigned) bp_unpack_value (bp, 1); TREE_NOTHROW (expr) = (unsigned) bp_unpack_value (bp, 1); TREE_STATIC (expr) = (unsigned) bp_unpack_value (bp, 1); if (TREE_CODE (expr) != TREE_BINFO) diff --git a/gcc/tree-streamer-out.cc b/gcc/tree-streamer-out.cc index ff9694e17dd..74f969478cf 100644 --- a/gcc/tree-streamer-out.cc +++ b/gcc/tree-streamer-out.cc @@ -105,6 +105,7 @@ pack_ts_base_value_fields (struct bitpack_d *bp, tree expr) bp_pack_value (bp, TYPE_ARTIFICIAL (expr), 1); else bp_pack_value (bp, TREE_NO_WARNING (expr), 1); + bp_pack_value (bp, TREE_USED (expr), 1); bp_pack_value (bp, TREE_NOTHROW (expr), 1); bp_pack_value (bp, TREE_STATIC (expr), 1); if (TREE_CODE (expr) != TREE_BINFO) -- 2.34.1