On Fri, Aug 18, 2023 at 7:13 PM Bradley Lucier <luc...@purdue.edu> wrote: > > On 8/17/23 3:54 AM, Richard Biener wrote: > > I think it needs a new category, 'inline' is probably the "closest" > > existing one > > but that also tends to be noisy. Maybe 'call' would be a good name? We > > could > > report things like tail-recursion optimization, tail-calling and sibling > > calling > > optimizations there, possibly also return/argument copy elision. > > OK, thanks. > > I have two questions: > > 1. Is the information dumped by -fopt-info intended for compiler > developers, to see something of the internal logic of gcc, or for end users?
-fopt-info is for the user. Note when you dump -all instead of -missed or -optimized you will get a lot of extra and eventually less useful things. Basically -fopt-info splices out info from passes that's both useful to users and also things that are mostly interesting to compiler developers (that's -all). > 2. You say that "'inline' ... tends to be noisy". Most of the output I > see from -fopt-info-missed is basically > > _io.c:103829:4: missed: not inlinable: ___H___io/396 -> > __builtin_expect/2486, function body not available > > Is ___builtin_expect truly a function whose body is not available, or > should -fopt-info-missed not report these instances? Yeah, that looks like a mis-classification to me. It's using the assigned CIF code (cif-code.def), and yes, we don't have a function body for __builtin_expect but that's not the reason we should present to users. Instead of MSG_MISSED_OPTIMIZATION for these class of callees we should use MSG_NOTE. At least to me a missed optimization should point out places we would eventually expect to be optimized either by providing enough of the constraints required in the source or by fixing a missed optimization capability in the compiler. Richard. > Brad
