[PATCH] D19397: Initial patch for inlining report
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Wed May 25 15:50:36 PDT 2016
hfinkel added a comment.
In http://reviews.llvm.org/D19397#436898, @rcox2 wrote:
> I’ve been looking at the patch that you posted for the annotated source listing to get an idea of how you would like the inlining report to conform to the diagnostic mechanism which you have already implemented.
> It seems to me that you would like the information needed to construct the inlining report to be passed back to the diagnostic mechanism via function calls like:
> when the inlining occurs, and
> when the inlining does not occur.
Yes (although you should use a proper subclass to store all of the relevant information in member variables). The other thing to track is the conversation about serialization of these things into YAML for consumption by external tools.
> Then, the report could be emitted in a manner similar to how you called OptReportAction::GenerateReportFile() for the annotated source listing.
Yes, although it sounds like the chosen path is to dump all of the information into YAML files, and then have the actual report generation in external tools that can consume those files, and the sources, to produce reports.
> Am I on the right track?
> To do so, I would need to pass down more information than is currently being passed down. I would need at least something that identifies the callsite either being inlined or not inlined, and, when reasons are added, the reason (or reasons) the inlining did or didn’t happen.
You mean into those functions? Yes, you'd need to use different functions (or directly create the remark classes and then directly call 'diagnose' with that class).
> Would I just add another parameter pointer to a class variable to do that?
> - Thanks, Robert Cox
More information about the llvm-commits