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: 140288 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp912559vqi; Fri, 15 Sep 2023 02:20:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFtSXysjMvQbvtsoYgAyPzt5M4kc3CagaDLEzB4aTBCRvGJhpeTCR8RwzSW7PR/p34VB0hw X-Received: by 2002:aa7:d953:0:b0:52c:a382:e0ca with SMTP id l19-20020aa7d953000000b0052ca382e0camr791687eds.41.1694769652211; Fri, 15 Sep 2023 02:20:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694769652; cv=none; d=google.com; s=arc-20160816; b=jmc0ns4DeHzfqzmF9Zr9QuDupVr33IJSoxYcvBjeZRgYkKmGL3BJRoDIZC2NV9bcMI VogYtUJKTvFK8O9QCG4X6UdBoDsc42nvFHvvmEwNTTygluTMyMW+efZ1dWiZ9Y0HO5Qg vqxMufer5BGjA6O9vvDvv9dF/nBNp3vz3DoG5lRFNujmLI8JJkKBnZx/443HaL8ZD5o0 6vSA0IiXnu0Y3crT0Qb0lFohsnJyk4mDx7BPf6bUXqcZsWN+86FP4dnJSQtahVVf+29M yIJCfmxcg7Sb3l8sFqtT4zzYz59dqCck5AFyyzYkjhe0m4i07bFVGbv1lbjoMGkw2Tqi oDRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mime-version:message-id:date :user-agent:subject:cc:to:from:ironport-sdr:dmarc-filter :delivered-to; bh=eyItAlepy5WJ3Y0X5rmG9H0m+eNGCtMxdzzxs196CrM=; fh=8BxGQU0v7tVsEISLQZLhWVf1qWAiy/UhTK5fOQDN82I=; b=oL1o/Q66q3RwIXiNlxiLM+4p8ck8vg49Voy7QzkHZLu9ft2hM7akeQ67hfsSgTXY+h /ed0PUPKcY9F8TR42mP3PSOtfMnbWZGlM76ASh4+LpKRD5f7ekB1oh5T4qKFNWwHsv2U h4mdO2SiIqTak7b6/LjYB78zUd4stZv6OAm9GgaaZGLpFjP44AGAxYKCrRL+DS29I3xS y18YcNVN4PMVxvI/LKKyGyAFL8xhR6JlpCWW9xklz+wz6MiWiIwWzwIxUJA+0x92bPuk tq/oB6z9+xl68tWtRYDB6n7OfKpM7INFwj9uDWbSi6T56O9GDqK8RFk13yydE10kt7kn ferg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id u15-20020aa7d88f000000b0052e81d36920si3075528edq.451.2023.09.15.02.20.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 02:20:52 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9CE913857707 for ; Fri, 15 Sep 2023 09:20:48 +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+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777094782327923894 X-GMAIL-MSGID: 1777094782327923894 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