From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id BB89D3856DE5 for ; Tue, 25 Oct 2022 21:05:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB89D3856DE5 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-x233.google.com with SMTP id r22so18905055ljn.10 for ; Tue, 25 Oct 2022 14:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YJUmZga/HZXav8DCR+UJ2xm5k/7WNAiaAhIh0Ki+Tds=; b=pcDVsEmTC3FNDYgzqHWqhmiy73wuCaEcJubTVjSiXQSaQLpSngiCSmW3gW+XZ90duA bz9IWI/w/3oKlMmfU3KaVize+WBD3FTAyi1AWBNSDWqIQmqgvTbBm91tdrzWOsomFvhU 2TuzRE0C4hJCLwXLa66SHfkmOO/mZ7O7snzmlCU7QTqY+fWJ8Dy62DWm3gBYZ5sHxmTQ s7nHfIEMCXj9Voz8xi7bZiE2Tjs9z3jnKL9UobjMKvoogyzX6e2Q3+aC6UMeV30OidMq ix83WPDvoMW6usXP+8cU0Lt+sT4iHi33aftsfxkHkE7KPm23rMonIzAZT5yle4YT6uKD 4iyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=YJUmZga/HZXav8DCR+UJ2xm5k/7WNAiaAhIh0Ki+Tds=; b=qJPdRGN18iGuaThigut9hf4VpXHx+vxFF8qW1bWowkQlyWCYg0wFVc/5Vv3LmFCd+9 cZnMCa9VV9ahWRJQ7aHpzcV0PiWodovTrrWveqgGFIlvGK8jIOGacMovJC3lpRaq45j3 fBp33NXG9cWLrqfD5G+Ay4KBtSPiZGwsiZ7t9jAsMrfAxX3/Itjp0Jo+LECz3hJJzNi3 cJDhPviotklPNOtOPhjm/KqcsQnXQKvY8L/4KFC2wcY0j4f362IGlgJl0Dsaneuir0Zn FSWFiQcmDIQ6X6zpaIxbiun3iSu2uKSbTmGsKNNQaF+U6GNTYz6NX2L8BEwrgql2OtTX sd3A== X-Gm-Message-State: ACrzQf1qzUmzr27DlNj75q8DkObFDpGhTSIOmDt78o6at/yRJb4MnRWs RYpA1DwQb6qyc1r9s+qma9QTwKjrTUvEaO4mQlA= X-Google-Smtp-Source: AMsMyM48DYkSNTtImSwVvZA7PRQsuiLMREsUYlO0Yid1di470uw5r/Ov/sozdu+VueCcsI6bm89Bk7w1p4DX/zwo4MQ= X-Received: by 2002:a2e:bd0e:0:b0:261:e718:e902 with SMTP id n14-20020a2ebd0e000000b00261e718e902mr16045462ljq.435.1666731946105; Tue, 25 Oct 2022 14:05:46 -0700 (PDT) MIME-Version: 1.0 References: <06ea9c1bd7e9b1493a1e740d8b6cf6f72be3db3e.1666220603.git.lhyatt@gmail.com> In-Reply-To: From: Lewis Hyatt Date: Tue, 25 Oct 2022 17:05:34 -0400 Message-ID: Subject: Re: [PATCH] diagnostics: Allow FEs to keep customizations for middle end [PR101551, PR106274] To: Richard Biener Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3029.7 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 Tue, Oct 25, 2022 at 7:35 AM Richard Biener wrote: > > On Thu, Oct 20, 2022 at 1:09 AM Lewis Hyatt via Gcc-patches > wrote: > > > > Currently, the ipa-free-lang-data pass resets most of the frontend's > > diagnostic customizations, such as the diagnostic_finalizer that prints macro > > expansion information, which is the subject of the two PRs. In most cases, > > however, there is no need to reset these customizations; they still work just > > fine after the language-specific data has been freed. (Macro tracking > > information, for instance, only depends on the line_maps instance and does not > > use the tree data structures at all.) > > > > Add an interface whereby frontends can convey which of their customizations > > should be preserved by ipa-free-lang-data. Only the macro tracking behavior is > > changed for now. Subsequent patches will add further configurations for each > > frontend. > > One point of the resetting of the hooks is to avoid crashes due to us zapping > many of the lang specific data structures. If the hooks were more resilent > that wouldn't be an issue. > Right. The patch I have for C++ (not sent yet) makes the C++ versions of decl_printable_name and and the diagnostic starter able to work after free_lang_data runs. I just worry that future changes to the C++ hooks would need to preserve this property, which could be error prone since issues are not immediately apparent, and most of the testsuite does not use -flto. > Now - as for macro tracking, how difficult is it to replicate that in the > default hook implementation? Basically we have similar issues for > late diagnostics of the LTO compile step where only the LTO (aka default) > variant of the hooks are present - it would be nice to improve that as well. > It is easy enough to make the default diagnostic finalizer print the macro tracking information stored in the global line_table. (It just needs to check if the global line_table is set, in which case call virt_loc_aware_diagnostic_finalizer()). This would remove the need for C-family frontends to override that callback. Fortran would still do so, since it does other things in its finalizer. However, this would not help with the LTO frontend because the line_table is not part of what gets streamed out. Rather the line_table is rebuilt from scratch when reading the data back in, but the macro tracking information is not available at that time, just the basic location info (filename and source location). I am not that familiar with the LTO streaming process but I feel like streaming the entire line_table would not mesh well with it (especially since multiple of them from different translation units would need to be combined back together). > Note free_lang_data exists to "simplify" the LTO bytecode output - things > freed do not need to be output. Of course the "freeing" logic could be > wired into the LTO bytecode output machinery directly - simply do not > output what we'd free. That way all info would prevail for the non-LTO > compile and the hooks could continue to work as they do without any > LTO streaming done. > Naively (emphasis on the naive, as I don't have any experience with this part of GCC), that is how I would have guessed it worked. But I understood there are some benefits to freeing the lang data earlier (e.g. reduced resource usage), and even a hope to start doing it in non-LTO builds as well, so I thought some incremental changes as in this patch to make diagnostics better after free_lang_data could perhaps be useful. Thanks for taking a look at it! -Lewis