[all-commits] [llvm/llvm-project] 9600a1: [analyzer] Workaround for slowdown spikes (uninten...

[Donát Nagy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9600a12f0de233324b559f60997b9c2db153fede
      https://github.com/llvm/llvm-project/commit/9600a12f0de233324b559f60997b9c2db153fede
  Author: Donát Nagy <donat.nagy at ericsson.com>
  Date:   2025-05-12 (Mon, 12 May 2025)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/FunctionSummary.h
    M clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
    M clang/test/Analysis/analyzer-config.c
    A clang/test/Analysis/loop-based-inlining-prevention.c
    M clang/test/Analysis/loop-unrolling.cpp

  Log Message:
  -----------
  [analyzer] Workaround for slowdown spikes (unintended scope increase) (#136720)

Recently some users reported that they observed large increases of
runtime (up to +600% on some translation units) when they upgraded to a
more recent (slightly patched, internal) clang version. Bisection
revealed that the bulk of this increase was probably caused by my
earlier commit bb27d5e5c6b194a1440b8ac4e5ace68d0ee2a849 ("Don't assume
third iteration in loops").

As I evaluated that earlier commit on several open source project, it
turns out that on average it's runtime-neutral (or slightly helpful: it
reduced the total analysis time by 1.5%) but it can cause runtime spikes
on some code: in particular it more than doubled the time to analyze
`tmux` (one of the smaller test projects).

Further profiling and investigation proved that these spikes were caused
by an _increase of analysis scope_ because there was an heuristic that
placed functions on a "don't inline this" blacklist if they reached the
`-analyzer-max-loop` limit (anywhere, on any one execution path) --
which became significantly rarer when my commit ensured the analyzer no
longer "just assumes" four iterations. (With more inlining significantly
more entry points use up their allocated budgets, which leads to the
increased runtime.)

I feel that this heuristic for the "don't inline" blacklist is
unjustified and arbitrary, because reaching the "retry without inlining"
limit on one path does not imply that inlining the function won't be
valuable on other paths -- so I hope that we can eventually replace it
with more "natural" limits of the analysis scope.

However, the runtime increases are annoying for the users whose project
is affected, so I created this quick workaround commit that approximates
the "don't inline" blacklist effects of ambiguous loops (where the
analyzer doesn't understand the loop condition) without fully reverting
the "Don't assume third iteration" commit (to avoid reintroducing the
false positives that were eliminated by it).

Investigating this issue was a team effort: I'm grateful to Endre Fülöp
(gamesh411) who did the bisection and shared his time measurement setup,
and Gábor Tóthvári (tigbr) who helped me in profiling.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications