[PATCH] D19678: Annotated-source optimization reports (a.k.a. "listing" files)

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D19678#419361, @rcox2 wrote:

> 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".
>
> If Hal wants to call what he is proposing the "optimization report", then we need to come up with another name for what I am proposing.


To be clear, I'm fine with calling this something else. How about "optimization summary" or "annotated optimization summary"? I could name the option -fannotated-optimization-summary, for example.

> To summarize what the Intel compiler has

> 

>   -qopt-report[=N]     where the default is 2 and the range is 1-5, with 1 having the least detail and 5 having the most detail 

>   -qopt-report-file=F   where F is a file name or stdout or stderr 

>   -qopt-report-phase=P where P is a sequence of phases (like ipo,cg, etc.) and only those phases are printed 

>   -qopt-report-filter=X  where X allows you to filter opt reports only for certain routines or parts of routines 

> 

> Use of ANY of these implies the generation of an opt report, so you don't need to say:

> 

>   -qopt-report -qopt-report-file=stderr

> 

> since

> 

>   -qopt-report-file=stderr 

> 

> is sufficient.

> 

> On a slightly different topic ....

> 

>        

> 

> One key question I have about Hal's proposal is whether there is any annotation associated with code that is inlined, beyond noting the call site that is inlined.

> 

> For example, if we have:

> 

>    int foo() { 

>        ... 

>        loop 

>        ....

>   } 

>   int main() { 

>       ...

>       foo(); 

>       ...

>    } 

> 

> and foo gets inlined, we have two loops of interest, the loop in foo() and the loop inlined into main().  Each of these could be vectorized, unrolled, etc. and it isn't always the case that both loops would have the same properties.  So, does Hal's report indicate info only about the loop in foo(), or are the properties of the two loops ANDed or ORed together and reported next to the loop in foo, or something else?

> 

> In general, you want info about both loops, and you can that with a classic optimization report.  But it's not clear how to effectively represent this on the lightweight annotated listing.  And it is often the case that the inlined loop is actually the more executed one, and therefore more important.


Currently, the information is ORed together. This has exactly the problem that you indicate, although the problem can be even worse than that: Functions are often transitively inlined multiple times into the same function, and users often want to know if the loops in those functions (or the inlining decisions themselves) differed each time. In the future, I'd like to detect this situation and present this information to the user. The common case (same behavior everywhere) should carry a succinct annotation, but otherwise we might want to do something like this:

  1234      |    for (...)
         V  |    ^
            |    * When inlined into foo (file.c:789), doit (d.c:45) -> bar (bar.c:234), not when inlined into work (work.c:345), doit (d.c:45) -> bar (bar.c:254)

Or we might just want to indicate that the annotation applies only to some places where the code was inlined and the user can generate a more-detailed optimization report for more information. I'm certainly open to suggestions, but I'd like to handle this in follow-up because it will likely require backend enhancements as well.

A related issue comes up with templated code; we might want to indicate the types when the optimizations end up being type dependent.


http://reviews.llvm.org/D19678