[PATCH] D103289: A post-processing for BFI inference

David Li via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 1 16:55:19 PDT 2021


davidxl added a comment.

In D103289#2791449 <https://reviews.llvm.org/D103289#2791449>, @spupyrev wrote:

> In D103289#2786306 <https://reviews.llvm.org/D103289#2786306>, @davidxl wrote:
>
>> thanks for working on this issue. A high level question -- is it possible to do the fix up on a per (irreducible) loop basis?
>
> Would you mind expanding on why you'd prefer a per-loop solution?

Mainly to reduce compile time overhead, but you have explained that it is not an issue.

> In general, we found that processing the entire control-flow graph (in opposite to identifying some "problematic" subgraphs first) is much easier from the implementation point of view, while it still keeps the alg fairly efficient. We have a notion of "active" blocks that are being updated, and the algorithm processes only such active vertices. Thus if the input counts are incorrect in a single loop, the algorithm will quickly learn that and will not touch the rest of the graph.





================
Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h:1388
+  // Extract initial frequencies for the blocks
+  DenseMap<const BlockT *, size_t> BlockIndex;
+  auto Freq = std::vector<Scaled64>(HotBlocks.size());
----------------
why is this map needed (which adds a layer of indirection)?


================
Comment at: llvm/include/llvm/Analysis/BlockFrequencyInfoImpl.h:1397
+  }
+  if (SumFreq.isZero())
+    return;
----------------
is it possible, given the blocks are hot?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103289/new/

https://reviews.llvm.org/D103289



More information about the llvm-commits mailing list