From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id CE0E53857421 for ; Fri, 28 Oct 2022 08:28:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CE0E53857421 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-ej1-x62b.google.com with SMTP id d26so11227376eje.10 for ; Fri, 28 Oct 2022 01:28:34 -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=Rxx3OLxkjWIA45hp5tejQ1xEK71hWvZFI31A9lq7nR8=; b=izLp+mH28W418sFiLE6WyxrStS99fLlpAwm6iICLCZJME1hJGwY9oYsUn/TPPghrpC fl3DpPVyH4ZjscaipwSL6uXMdf7XDcNvGJL0WfXVuKJH/LKx9LxTHj/G9cINDBDWjNJN fihns6dTwmXUV2vu2Ty+qlFOwq3OdQNkDzdTZ/hZxB8L6PS78LA4PAfv4Ta1FENj8CKp +UOSU8Rm50NYo7F6CVDrEnV1VyQmYxoFnQAJ7GrXhxOtZ7I/Lfv/6UG9C9v/JEYie+fu kdUmlnJvr4qgosCIdI/mJALDnPRj94bzrqefBhsSkeRy9XzD4hp4Ev9hBcfcSBggMreG afbg== 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=Rxx3OLxkjWIA45hp5tejQ1xEK71hWvZFI31A9lq7nR8=; b=Eh8Fns4liY3boKWlVQLObx9DAjpPcmBdv9D+HAD8E6SvQdzr+Ak4PoK6SSEJv73HwJ /Fpq7qSTmXv5kYAIp4HK+Z3hCAAqK+6Z7XSpSb5F6jxVZ8bfhl1GrU4fYz6KLo7CoC6p 30obxz7TlMPSVx5guFBz2ql1K/+ztNiR7RCa89F786J+gq8c0nX4TiOdKCfcrBeIdiOL r4EfMYGCE8DOSSqkJNJveYrPrH+Nl5+z+IX57zwPlqJmgaL5Ps2KapJOqikYOVv6wnvk 8EVcc46o3YhmUqar+kL1v2FbGkd3Oh8+5Y4k2WXameMmU7NtdDy7Izsv2Vj8j6+4W0YC qRxw== X-Gm-Message-State: ACrzQf3Jl/ML/afLnOoDRUKBkyQFN3hrJoa6EIzyXhgJHA6Ne2w9L4L7 03mF2MnwU8aGklneR24n6tP+JF3r1xkIam33sSw= X-Google-Smtp-Source: AMsMyM54lb70WK6Ri4IhNs4KsST7uaw/KHO14R3cRNwKQQJu+QJfOKJ6kDc8bFPLHzHa2nieoAgGyztdJARDjksdQCQ= X-Received: by 2002:a17:907:2c68:b0:7ad:8ba7:664a with SMTP id ib8-20020a1709072c6800b007ad8ba7664amr7297254ejc.488.1666945713590; Fri, 28 Oct 2022 01:28:33 -0700 (PDT) MIME-Version: 1.0 References: <06ea9c1bd7e9b1493a1e740d8b6cf6f72be3db3e.1666220603.git.lhyatt@gmail.com> In-Reply-To: From: Richard Biener Date: Fri, 28 Oct 2022 10:28:21 +0200 Message-ID: Subject: Re: [PATCH] diagnostics: Allow FEs to keep customizations for middle end [PR101551, PR106274] To: Lewis Hyatt , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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 11:05 PM Lewis Hyatt wrote: > > 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! Yes, the idea was also to free up memory but then that part never really materialized - the idea was to always run free-lang-data, not just when later outputting LTO bytecode. The reason is probably mainly the diagnostic regressions you observe. Maybe a better strathegy than your patch would be to work towards that goal but reduce the number of "freeings", instead adjusting the LTO streamer to properly ignore frontend specific bits where clearing conflicts with the intent to preserve accurate diagnostics throughout the compilation. If you see bits that when not freed would fix some of the observed issues we can see to replicate the freeing in the LTO output machinery. Richard. > > -Lewis