On Mon, Aug 7, 2023 at 9:04 PM Bradley Lucier <luc...@purdue.edu> wrote: > > Thank you for your comments. I have a few questions. > > > I don't think this specific case qualifies for -Wdisabled-optimization. > > The diagnostic is for cases the user can control and was invented > > for limits we put up for compile-time and memory-usage issues > > where there exist --param XYZ to adjust limits. > > > > It would be more appropriate to change this to > > > > dump_printf_loc (MSG_MISSED_OPTIMIZATION, ...) > > > > where this was designe to diagnose cases the compiler failed to > > optimize for other reasons than running into some --param. > > I'm sorry, I don't understand what dump_printf_loc does, where does it > dump this information? What is the form of information that is usually > dumped, and for which purpose?
dump_printf_loc is able to direct the information to multiple places, for one it amends the IL/pass dump file produced with -fdump-tree-<passname>, but it also produces information for the -fopt-info* family of switches. For example -fopt-info-vec produces a set of vectorized locations as diagnostics, -fopt-info-vec-missed a set of diagnostics related to missed vectorization opportunities. GCC recently gained the ability to format some of the diagnostics as SARIF, I'm not sure if -fopt-info related diagnostics are covered, but at least -fsave-optimization-record produces JSON output. So we now have a better and more general machinery to diagnose optimized/missed optimized things for passes than -Wdisabled-optimization and _disabled_ optimization should now be taken literally when the optimization was disabled by the user via a (default) choice of a --param value for example (or a conflicting different optimization option). The granularity for reporting -fopt-info is optimization groups (see dumpfile.h, the OPTGROUP_* enum), I believe maybe_complain_about_tail_call invocations are all from RTL expansion which currently is OPTGROUP_NONE which would have to change (I think it's currently not possible to explicitely specify an alternate optgroup at dump_printf time (David?). So the simplest way forward would be to add, say, OPTGROUP_EXPAND, use dump_printf in maybe_complain_about_tail_call (which will also dump info to the .expand debug dump which looks useful) and recognize -fopt-info-expand. > > So, NAK. > > What does "NAK" mean? not acknowledged > When I added the -Wdisabled-optimization warning to gcc in 2000, I was > trying to give the user information about when the compiler may not do > an optimization that the user asks for. And yes, my idea was that the > user can either ignore the warning or do something to the code or change > a --param to allow the optimization to succeed. > > Whether gcc actually optimizes tail or sibling calls that appear in the > Gambit source code has been a point of discussion among the Gambit > Scheme community for years; sometimes that discussion has bled into the > GCC mail lists, there's a fairly long thread here: > > https://gcc.gnu.org/pipermail/gcc-help/2021-December/140957.html > > I actually built a profiled gcc to see whether > maybe_complain_about_tail_call was called when compiling the output of > Gambit's Scheme->C compiler; afterwards I reported to the Gambit mail > list that it had not, all sibling calls were optimized. > > To me, -Wdisabled-optimization seems very appropriate when the user asks > explicitly for -foptimize-sibling-calls (which the Gambit makefile does, > because it doesn't want all -O2 optimizations) and a sibling call can't > be optimized. > > maybe_complain_about_tail_call is even passed a helpful message that > explains *why* the call can't be optimized. With this information, the > user can actually do something, rewrite the code to remove the obstacle, > or decide that optimizing that particular call isn't important (which > sometimes it isn't, if it's in the handwritten C support library instead > of the C code generated by the Scheme->C compiler). > > So I'm really hoping that some kind of information can be sent back to > the user in this situation. > > Brad
