[PATCH] D152834: A new code layout algorithm for function reordering [2/3]

Sergey Pupyrev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 14 11:55:25 PDT 2023


spupyrev added inline comments.


================
Comment at: llvm/include/llvm/Transforms/Utils/CodeLayout.h:56
 
+/// Algorithm-specific params for Cache-Directed Sort. The values are tuned for
+/// the best performance of large-scale front-end bound binaries.
----------------
rahmanl wrote:
> spupyrev wrote:
> > rahmanl wrote:
> > > Please introduce cl::opts for these so they can be manually configured.
> > Based on my experience, exposing such constants doesn't add much value but may confuse some people. For example, C^3 has a bunch of similar options tuned once on a specific benchmark years ago, and no one has ever tried to re-consider them :) A have similar experience for other algorithms, where the defaults were never touched. At this time I consider the values as some internal algorithm-specific constants that are not supposed to be modified.
> > However, cl:opts take just a few lines of code, so i'm happy to add those if you have an alternative opinion.
> > 
> The configurations here look very architecture-dependent. So I am assuming that as hardware improves, we may increase these parameters to get a better result. WDYT?
Added


================
Comment at: llvm/lib/Transforms/Utils/CodeLayout.cpp:1294
+    // Merge the edges
+    Into->mergeEdges(From);
+    From->clear();
----------------
rahmanl wrote:
> I wonder if this could be a source of performance drop for larger programs. These chains are much bigger than the block chains and could have more edges with other chains. However, we currently use std::vector for `ChainT::Edges` and removing things from a vector one by one could result in quadratic time complexity. So a potential optimization is to remove all outdated edges in one shot using the combination of `vector::erase` and `std::remove_if`.
As far as I can see, `ChainT::mergeEdges` does a bit more than removing the items from the vectors; I don't see a simple way of reducing the complexity here. (But I am open for reviewing speedups of course)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152834



More information about the llvm-commits mailing list