[PATCH] D50094: Introduce DebugCounter into ConstProp pass

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

IIUC by always adding to the end of WorkListVec, we could end up using substantial more memory, depending on the input program. In practice it shouldn't be too bad, as I think an upper bound for the times an instruction is added to WorkListVec is the number of operands (it will only get added if one of its operands gets constant folded, and once an operand is constant folded, it won't get folded again). And usually most instructions have a small number of operands.

However, I think we might be able to construct programs  where WorkListVec uses O(n*n) memory (where n is the number of instructions): say we have n/2 instructions where Inst_x can be constant folded after Inst_(x-1) got constant folded. The other n/2 instructions are PHI nodes with with all other n/2 instructions as incoming values. Now we process them in the most suboptimal order: first all the phi nodes, then Inst_(n/2).... Inst_0. We manage to constant fold Inst_0 and add n/2 phi nodes and Inst_1 to WorkListVec. We again process all phi nodes, constant fold Inst_1 and add all phi nodes and Inst_2. We continue doing until all n/2 non-phi instructions are constant folded and each time we add n/2 nodes to WorkListVec.

Not sure if it is worth it (as this is a legacy pass and not used any more AFAIK), but I think we could use 2 worklists to keep the memory usage linear, with keeping the same iteration order:

  while (!WorkList.empty()) {
     SmallVector<Instruction*, 16> NewWorkListVec;
     for (auto *I : WorkListVec) {
       ......
           NewWorkListVec.push_back(U);
       .....
     }
     WorkListVec = std::move(NewWorkListVec);
  }



================
Comment at: lib/Transforms/Scalar/ConstantProp.cpp:109
         // Remove the dead instruction.
         WorkList.erase(I);
         if (isInstructionTriviallyDead(I, TLI)) {
----------------
already erase at line 90?


Repository:
  rL LLVM

https://reviews.llvm.org/D50094