[PATCH] D60295: [CodeGen] Replace -max-jump-table-size with -max-jump-table-targets

Evandro Menezes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 15 18:06:52 PDT 2019


evandro marked 2 inline comments as done.
evandro added inline comments.


================
Comment at: llvm/lib/CodeGen/SwitchLoweringUtils.cpp:156
       NumCases = getJumpTableNumCases(TotalCases, i, j);
+      NumTargets = getJumpTableNumTargets(Clusters, i, j);
+      MaxTargets = NumTargets + (HasReachableDefault && Range > NumCases);
----------------
hans wrote:
> evandro wrote:
> > hans wrote:
> > > Hmm, this is problematic. getJumpTableNumTargets has linear time complexity in the number of clusters, so I think this is essentially adding another factor O(n) to the overall time complexity, which is unfortunate.
> > > 
> > > One way to solve this within the original O(n^2) complexity of the current code, would be to build an auxiliary data structure in the outer for-loop, e.g. TotalNumTargets[], where TotalNumTargets[x] is the total number of targets in clusters i..x (i being defined in the outer loop).
> > > 
> > > That would be built in O(n) time, and the inner loop would then query TotalNumTargets[j] (in constant time).
> > > 
> > > 
> > If I understood you correctly, pre calculating  the number of targets in clusters i..x, where x will be j, is the same as performing this calculation inside the inner loop.
> No, the current code does O(n) work in the inner loop, making the overall time complexity O(n^3). Pre-computing the number of targets in clusters i..x in the outer loop would preserve the overall time complexity of O(n^2).
Let me see if I understood what you mean in a patch...


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

https://reviews.llvm.org/D60295





More information about the llvm-commits mailing list