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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
