Hi Craig Topper,
I noticed a regression after this change set hit our repository at Intel. The code in llvm/lib/Transforms/IPO/FunctionAttrs.cpp has a function checkFunctionMemoryAccess() that is not checking for intrinsics which may have side effects. This causes the inliner to remove a function as trivially dead when it only has a ldmxcsr instruction and some setup and shutdown code. I could change the line:

if (!AliasAnalysis::onlyAccessesArgPointees(MRB))

to

if (!AliasAnalysis::onlyAccessesArgPointees(MRB) || I->mayHaveSideEffects()) {

but I do have some concern whether this will be overly conservative.
Any thoughts?

• Robert Cox from Intel (rcox2)

No comments on this review, yet. Any chance the reviewers I picked will be able to look at it in the near future? Should I add some other names? -- Thanks, Robert

In D19397#440168, @hfinkel wrote:

In D19397#436898, @rcox2 wrote:

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.

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.

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.

Of course, it would be my preference to mirror the functionality of what is available in the "new" hierarchical form of optimization report Intel compiler. So, I would like to distinguish between what Hal is proposing (which we call an "annotated listing") and what I am proposing, which we call an "optimization report".

Actually, the Intel compiler distinguishes between an optimization report (-qopt-report) and an annotated listing (-qopt-report-annotate). The optimization report lists the info for optimizations in a hierarchical fashion. To use you example,

icc -c -O3 -qopt-report=1 -qopt-report-file=stderr v.c

yields:

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.