[PATCH] D19397: Initial patch for inlining report

[Robert Cox via llvm-commits]

rcox2 added a comment.

Hal,

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:

emitOptimizationRemark()

when the inlining occurs, and

emitOptimizationRemarkMissed()

when the inlining does not occur.

Then, the report could be emitted in a manner similar to how you called OptReportAction::GenerateReportFile() for the annotated source listing.

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.

Would I just add another parameter pointer to a class variable to do that?

- Thanks, Robert Cox


http://reviews.llvm.org/D19397