On Tue, Oct 25, 2022 at 11:05 PM Lewis Hyatt <lhy...@gmail.com> wrote: > > On Tue, Oct 25, 2022 at 7:35 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On Thu, Oct 20, 2022 at 1:09 AM Lewis Hyatt via Gcc-patches > > <gcc-patches@gcc.gnu.org> 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
