[PATCH] D147812: [InstrProf] Use BalancedPartitioning to order temporal profiling trace data

Sergey Pupyrev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 14 12:22:55 PDT 2023


spupyrev added inline comments.


================
Comment at: llvm/include/llvm/Support/BalancedPartitioning.h:88
+  /// The depth of the recursive bisection
+  uint32_t SplitDepth = 16;
+  /// The maximum number of bp iterations per split
----------------
I thought we use `18` by default?


================
Comment at: llvm/lib/Support/BalancedPartitioning.cpp:85
+
+void BalancedPartitioning::BPThreadPool::wait() {
+  // TODO: We could remove the mutex and condition variable and use
----------------
Would be great to unify the implementation with the existing ThreadPool, but I don't have a suggestion on how exactly to implement that. I'm fine with keeping it as is, if there are no alternative suggestions.


================
Comment at: llvm/lib/Support/BalancedPartitioning.cpp:214
+  // is 4x larger than the number of FunctionNodes.
+  SignatureMapT Signatures(/*InitialReserve=*/NumNodes * 4);
+  for (auto &N : Nodes) {
----------------
Do we want to get rid of the map? (and the weird 4x initialization)


================
Comment at: llvm/lib/Support/BalancedPartitioning.cpp:366
+double
+BalancedPartitioning::computeGoal(const SignatureMapT &Signatures) const {
+  double Sum = 0;
----------------
I think we've got rid of this method


================
Comment at: llvm/tools/llvm-profdata/llvm-profdata.cpp:3046
+      "cutoffs", cl::CommaSeparated,
+      cl::desc("Timestamp cutoff values used to initialize function nodes for "
+               "ordering functions"),
----------------
davidxl wrote:
> ellis wrote:
> > davidxl wrote:
> > > How are the default values selected?
> > These values were also empirically found by optimizing a large binary. I was debating leaving out a default value since these values are pretty specific to the binary we tested. Now that I think about it, we can try to derive a similar list by looking at the total number of functions and assign cutoffs linearly.
> or add some empirical guidance in the description.
The assumption here is that most of the traces are of size ~32K. Perhaps we could also add a comment and a clarification to re-consider the values, if the traces are of significantly different sizes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147812



More information about the llvm-commits mailing list