This is an archive of the discontinued LLVM Phabricator instance.

Pass to compute dynamic instruction count
AbandonedPublic

Authored by eraman on Oct 14 2015, 4:01 PM.

Details

Reviewers
chandlerc
hfinkel
Summary

An analysis pass in the new PM to compute estimated dynamic instruction count of a function based on the static instruction count and block frequency info. The intention is to use this in inline cost analysis to estimate speedup due to inlining (as discussed in the RFC I sent earlier).

We want the static instruction counts to be closely tied to the cost model used in inline cost analysis. I have moved the CallAnalyzer interface to the header file. When used on out-of-line function, the code in CallAnalyzer that tries to simplify instructions is mostly irrelevant. In most cases, this works fine based on the fact that the initial map of known values is empty. In some cases, I need an explicit flag to distinguish whether I'm using the analyzer during inlining or not.

Diff Detail

Repository
rL LLVM

Event Timeline

eraman updated this revision to Diff 37407.Oct 14 2015, 4:01 PM
eraman retitled this revision from to Pass to compute dynamic instruction count.
eraman updated this object.
eraman added reviewers: chandlerc, hfinkel.
eraman set the repository for this revision to rL LLVM.
eraman added a subscriber: llvm-commits.

Drive by question:

Why a pass and not a utility?

(Admittedly not read the code, just the description)

Thanks!

-eric

Can you split the patch the move the call analyzer to the header into a separate one? That is an ok one by its own.

davidxl added inline comments.Oct 19 2015, 10:47 AM
include/llvm/Analysis/InlineCost.h
162

Can you explain why it is needed for out-of-line functions -- basically explain how DynamicInstructionCountAnalysis is going to be used. Also why can't the use of frequency/profile information be baked into CallAnalyzer itself?

hfinkel added inline comments.Oct 27 2015, 3:55 PM
include/llvm/Analysis/InlineCost.h
165

I like the fact that the inlining-specific behavior can be explicitly disabled using this flag, but this needs to be better documented. At least give a few examples here of what kind of inlining-specific behavior this enables.

eraman added a subscriber: eraman.Nov 2 2015, 4:47 PM

I'm dropping the patch for now. The argument for making this as a pass is
to allow it to be shared by some client other than inliner (LoopUnroller?
something else?). But then, tying it to the cost model used by inliner
doesn't make sense. I can't rewrite this patch as a library now before
switching to the new pass manager, so I'll drop this now and revisit this
later.

eraman abandoned this revision.Dec 11 2015, 4:35 PM