From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id BD8B93858D1E for ; Fri, 15 Sep 2023 10:11:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD8B93858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2b703a0453fso32396571fa.3 for ; Fri, 15 Sep 2023 03:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694772717; x=1695377517; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Jf3ggSZF/mcCBRt9aw+fF3FC8RLK+dG0p5A7gl1Qinc=; b=Wt8E/hVPzL5Gje4gCIUVO8J6Jm+KxQuhr4O3oWlBb8n2OfZjAuUHHreqMDEvxWnOAH dcEeIfWUe6pxTj88Ipwu2vEBpFMdrNvPxWHmxDfHZo06P9quz8BvXGASeySQA2X8xvYI XZj40zvBC4JUellLwHj8BJtU4xszPF7T4klRcrY3oNkJL1z/820WWuSQGHtqnuoncBv1 iqBYrvSEUtO/6yNsmRXonz5PjFsAs3IiFZF+jyCi5dOhq7QPt3YnG/05du9JjtFILnm3 EaHsuXuT7bHXlCRLAOBFVb7bz8daa01jlB38bIBfRDxZ/ReCrzArCRb69ev0Brme4EWD L8ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694772717; x=1695377517; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Jf3ggSZF/mcCBRt9aw+fF3FC8RLK+dG0p5A7gl1Qinc=; b=fMclUA5vqhCcBqPegP+JuqFYdx5o77exOT4U4Bj13mzJVRHX8xzRfmfK+Kg0SXWi0D QxgVJXm897ZRNk54d/0NTDQjVOhBPhO3smGcA3/8udzmtmTGDrrps/OCjQ17sDYo0Z5a wUGT1WorjgRAyuZQmtIOmDmXGAWAFDo6JYKD2kNyZtfthfDLhazjeZdD3Muu6Yv3Orkv QpWj4yBm5G76khbnPU8O7Dc+qIWABQuAkB6JaxUhlWpPafjvdb+QuctmbthEoYa5b3x6 our4hB2mWPnIcSTCvpxQjH9D3QFkdVWQAOLsZnRYFLK3YGW9uxWjAVxdG5Kgs/HfAy4L 406A== X-Gm-Message-State: AOJu0YyXT+6XNsr0qG2GjbbG2XE98nTpnwfL4Ow1JUR5ICF1ltXCkAPG +aHDdI0fAT+LFbv6HSSgLpKg0e8vot0PA1915mI= X-Google-Smtp-Source: AGHT+IFkUWie7BPEi7QTxTCCdCrZ3TeZ9jeQXH22xWkG1nyuquPNyiqioLq6CEBdCqJ5sCK77cwJrmRO3cBY8hLMKF4= X-Received: by 2002:a19:4353:0:b0:502:d7ec:fc68 with SMTP id m19-20020a194353000000b00502d7ecfc68mr859946lfj.9.1694772716787; Fri, 15 Sep 2023 03:11:56 -0700 (PDT) MIME-Version: 1.0 References: <87jzsryerg.fsf@euler.schwinge.homeip.net> In-Reply-To: <87jzsryerg.fsf@euler.schwinge.homeip.net> From: Richard Biener Date: Fri, 15 Sep 2023 12:11:44 +0200 Message-ID: Subject: Re: [WIP] Re-introduce 'TREE_USED' in tree streaming To: Thomas Schwinge Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Tobias Burnus , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 List-Id: On Fri, Sep 15, 2023 at 11:20=E2=80=AFAM Thomas Schwinge wrote: > > Hi! > > Now, that was another quirky debug session: in > 'gcc/omp-low.cc:create_omp_child_function' we clearly do set > 'TREE_USED (t) =3D 1;' for '.omp_data_i', which ends up as formal paramet= er > 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? TREE_USED is considered stale, it doesn't reflect reality and is used with different semantics throughout the pass pipeline so it doesn't make much se= nse to stream it also because it will needlessly cause divergence between TUs during tree merging. So we definitely do not want to stream TREE_USED for every tree. Why would you guard anything late on TREE_USED? If you want to know whether a formal parameter is "used" (used in code generation? used in the source?) you have to compute this property. As you can see using TREE_USED is fragile. > 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=C3=BC=C3=9Fe > Thomas > > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955