[NFC][Coverage] Do not use recursion for GCOV propagateCounts. #68455
Conversation
This causes stack overflows for some real-world kernel libraries. Ran $ build/bin/llvm-lit -a llvm/test/tools/llvm-cov locally and passed.
|
Hey @jroelofs thanks for LGTM! But I don't have permission to merge this change :< |
| Current.Pred->count = Current.Excess; | ||
|
|
||
| // updates parent Excess value | ||
| if (Current.IsInSrcs) { |
There was a problem hiding this comment.
| if (pred) | ||
| pred->count = excess; | ||
| return excess; | ||
| if (Idx == 0) { |
There was a problem hiding this comment.
There was a problem hiding this comment.
Thanks for the change but please give me time to review and don't hurry on merging.
This causes stack overflows for some real-world kernel libraries.
Is there an internal bug I can take a look.
The maximum depth is bounded by the longest tree edge (Kirchhoff's circuit law optimization I added to llvm/clang gcov). If all tree edges are correctly computed, an overflowed stack (default 8MiB) suggests a really huge number of basic blocks in the function. Is it really the case? If not, we need deep analysis.
If iteration is really needed for propagateCounts, I'd prefer a style similar to augmentOneCycle (where I lowered the time complexity to O(E^2)).
|
Perhaps your environment has a smaller default stack size? I have a simplified iterative algorithm: https://github.com/maskray/llvm-project/tree/gcov-propagateCounts I take the opportunity to add what the function is about: See the edge propagation algorithm in Optimally Profiling and Tracing Programs, ACM Transactions on Programming Languages and Systems, 1994. |
propagateCounts computes unmeasured arc counts (see commit b9d0866). In a x86-64 build using -O3 -fno-omit-frame-pointer, propagateCounts uses 80 bytes per stack frame. If a function contains 1e5 basic blocks on a tree path (Kirchoff's circuit law optimization), the used stack space will be 8MB (default ulimit -s in many configurations). (In a -O0 build, a stack frame costs 224 bytes.) 1e5 is ample for most configurations. However, for library users using threads (e.g. in RPC handlers), a remaining thread stack of 64KiB allows just 819 stack frames, which is too limited. Switch to an iterative form to avoid stack overflow issues. Iterative forms match other iterative form functions in this file (https://reviews.llvm.org/D93073). Alternative to #68455
|
The issue here was solved by 776e456 instead. |
This causes stack overflows for some real-world kernel libraries.
Ran $ build/bin/llvm-lit -a llvm/test/tools/llvm-cov locally and passed.