This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

-fopt-info-inline and class opt_problem


On Thu, 2018-10-04 at 12:52 +0200, Richard Biener wrote:
> On Fri, 28 Sep 2018, David Malcolm wrote:

[...snip...]

> > 
> > OK for trunk?
> 
> OK.  My question on 2/3 leaves Richard time to comment.
> 
> Maybe you can tackle the issue that -fopt-info-inline does
> nothing at the moment and see if opt-problems are a good fit
> there as well (reporting the CIF strings).

Thanks.  I've committed the patch kit.

[CCing Honza]

I'm looking at -fopt-info-inline now (PR ipa/86395).  I might look at
loop optimizations also (there are some fprintfs there also).

Presumably the user-experience for -fopt-info-inline should be
something like:

  <CALLSITE-LOCATION>: missed: can't inline foo into bar
  <REASON-LOCATION>: missed: because of <REASON>

or:

  <CALLSITE-LOCATION>: missed: not inlining foo into bar
  <REASON-LOCATION>: missed: because of <REASON>

and:

  <CALLSITE-LOCATION>: optimized: inlined foo into bar

(gathering all pertinent data into the -fsave-optimization-record
output).

I suspect that the opt_problem class from the above patch kit [1] isn't
a good fit for inlining: the loop vectorizer runs one outer loop at a
time, with a deep callstack, needing to bubble up a single "problem" at
at time.

In contrast, assuming I'm reading the code right, the inliner stores a
status in each cgraph_edge, and walks the cgraph to decide what to do
with all of the edges, with a fairly shallow callstack: I believe
decisions made for one edge can affect other edges etc.

It might still be possible to store and/or emit a bit more per-edge
detail other than the plain enum cgraph_inline_failed_t, if that's
desirable.

Brainstorming:

(a) replace the "inline_failed" enum with a pointer to a class that can
contain more details (perhaps an opt_problem subclass): in a normal
dump-disabled setting, these would point to global constant singletons
(so no allocation is needed); in a dump-enabled setting, these could be
allocated objects containing additional details describing *exactly*
why an edge wasn't inlined (but this adds lots of indirections, ugh)

(b) add a map of cgraph_edge to opt_problem instances; this would only
be populated if dumping is enabled.

(c) if dumping is enabled, generate an opt_problem when an edge
transitions to CIF_FINAL_ERROR, and emit it... somewhere.

I'm not sure if the above are good ideas or not.  (b) and (c) feel more
credible than (a).


Dave

[1] https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01747.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]