[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