[PATCH] D38768: Add remarks describing when a pass changes the IR instruction count of a module

Jessica Paquette via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 13 11:38:43 PDT 2017


paquette marked an inline comment as done.
paquette added inline comments.


================
Comment at: lib/IR/LegacyPassManager.cpp:132
 
-
-
+int PMDataManager::getModuleInstrCount(Module &M) {
+  int Instrs = 0;
----------------
davide wrote:
> This doesn't really belong to `PMDataManager`, if we want something like this it could probably live in `Module`. 
> 
> I'm also slightly concerned as this seems to recompute the number of instruction for the whole module every time you run a function pass.
> If your TU gets large (e.g. LTO) the overhead will be substantial. 
> We might strive a more incremental approach, but it's not immediately clear to me how (I'll think about it)
If we only keep track of deltas, then we might be able to do better. Then the question is how much the actual size of the module at every step matters.

For example, if a function pass modifies the size of the program, then we know how many instructions it changed simply by getting the size of the function it acted on before and after the pass. We can then emit a remark with that delta. That would still give us a measure of how much passes change code size. You would still be in trouble with module passes, but it'd at least reduce the overhead for FunctionPasses and their ilk.


================
Comment at: lib/IR/LegacyPassManager.cpp:148-149
+  // If it's a pass manager, don't emit a remark.
+  if (P->getAsPMDataManager())
+      return;
+
----------------
davide wrote:
> I'm not sure I understand this one, can you please give an example?
Only pass managers return non-null on getAsPMDataManager. Thus, we can tell whether or not a pass is a pass manager by checking this. It's also used in the same way later in the file in the TimingInfo class. I should probably elaborate more in the comment as well.

It seems more reasonable to use the PassKind that each pass carries around. However, that doesn't work for the inliner's pass manager, which is categorized as a PT_Module. Thus, you end up getting a remark for both the inliner and its pass manager.


https://reviews.llvm.org/D38768





More information about the llvm-commits mailing list