[LLVMdev] Any objections to my importing GoogleMock to go with GoogleTest in LLVM?

[Sean Silva]

On Fri, Nov 15, 2013 at 2:12 AM, Sean Silva <silvas at purdue.edu> wrote:

> - non-intrusively collect detailed information/statistics about the
> optimization pipeline. For example, which pass is responsible for
> eliminating the most functions? Which pass is responsible for eliminating
> *this* instruction in my function?
>
>
In general, improved observability into the optimization pipeline can have
possibly huge knock-on effects for improving it.

Not entirely kidding:

A sort of "pass-pseudo-dtrace" could be implemented in a nicely independent
way by defining "probes" at the various locations exposed by the
"introspection" API (no actual dynamic instrumentation; it just executes
stuff in those "introspection" callbacks). Silly strawman oneliner:
    opt -pass-pseudo-dtrace='pass:*::before { self->shl_before =
curmodule["shl"].count() } pass:*::after /curmodule["shl"].count() <=
self->shl_before -  5/ { print(curpassname, "managed to eliminate more than
5 shl's!") }' foo.bc
My experience with dtrace is that such trivially available observability
and powerful ad-hoc queries (and the deeper investigations they lead to and
facilitate) are the single most effective way to identify
previously-unknown things that could be improved (or that are broken) in a
system.
Even purely as a learning tool it might be worth having that.

How else would you answer the question "which passes eliminate shl's in a
typical compilation"? (and that's just one of an open-ended class of
queries that such a system would facilitate).

AFAIK the only way to currently answer that question is to drop down to
C++, write a pass that gathers the statistics, hack up opt to insert these
instrumentation passes between passes in the desired pipeline (or do some
horrible brittle commandline transformation), rebuild things (possibly
rebuilding most of LLVM if you don't already have an incremental build
hot): end result is that it would take at least an order of magnitude more
time (or even 2). If you have to shave a yak to get an answer, you ask
fewer questions.

(Note: while you may be able to name some passes that eliminate shl's off
the top of your head, it's precisely the ones that you *can't* think of off
the top of your head that have the potential to expose unexpected
properties of the system). Adding &&'s and ||'s quickly moves you into a
realm where even gurus can at best guess: maybe a step up in complexity is:
partition the set of passes into the 9 categories defined by
"{add,remove,not change} load's && {add,remove,not change} shl's", are
there any categories that are unpopulated?. And conjunctions and
disjunctions barely scratch the surface of what such a "dtrace-like" system
can easily access (e.g. how does the average integer size in the module
change throughout the optimization pipeline? generate data that can be used
for plotting a line-graph. Which passes have the largest impact on average
integer size?).

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131115/ed01b580/attachment.html>