On Tue, 2023-08-08 at 08:05 +0200, Richard Biener wrote: > 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,
FWIW the SARIF output doesn't contain the -fopt-info stuff. > 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?). IIRC, the dumping machinery tries to consolidate the dump messages into "optinfo" instances, where a dump_*_loc call starts a new optinfo, and it's then that the optgroup can be specified. But it's been a while since I last looked at this code. > > 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. [...snip...] Dave
