[PATCH] D19397: Initial patch for inlining report

[Hal Finkel via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D19397#413328, @hfinkel wrote:

> In http://reviews.llvm.org/D19397#409261, @rcox2 wrote:
>
> > Having a high level Report class would be useful.  I talked to a few people at the Bay Area LLVM Social and they supported the idea of Report class into which all optimizaitons could report information.
> >
> > The key difference between that and the remark mechanism is that the remark mechanism provides a way to give a "blow by blow" description of what optimizations have or haven't happened in time sequence.  An optimization report (of which the inline report would be a first part) organizes the information in a more useful hierarchical and analyzable form.
> >
> > Most applications that I look at have on the order of 10s of thousands of inlining decisions.  Simply having them printed out in sequence, as is done with the optimization remarks, does not yield the info in a form that guides the user to act on it.
>
>
> It is true that the current remark system prints out a "blow by blow" description, but the general infrastructure is not limited to that -- the frontend handler can do whatever it wishes. Furthermore, the entire remark system (DiagnosticInfo) was designed to allow the information to flow through the frontend so that various embedded analysis and display tools might intercept it. LLVM provides default handlers and printers. We should follow the same pattern here.
>
>   InliningInformation (collected during inlining) -> Set to Frontend (via the DiagnosticInfo class system) ->
>     Frontend collects information  -- by default, it collects the information and prints it at the end into a report file [LLVM provides a default printer that all frontends can use if desired (all diagnostics and remarks can print themselves using some DiagnosticPrinter class)].
>   
>
> In short, the desired state is not necessrily too far removed from what you have, but it needs to be refactored a bit to fit into the infrastructure we have (and that we designed to be flexible enough to serve a wide variety of use cases)


Please see also http://reviews.llvm.org/D19678, as an example of intercepting the remarks in the frontend and doing something other than just printing them. This is not really "right" because the relevant remarks are not yet proper subclasses, but we can fix that up in parallel. Also feel free to help with that review.


http://reviews.llvm.org/D19397