https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109252
Bug ID: 109252
Summary: RFE: make use of existing GCC loop analysis within
-fanalyzer (or otherwise revamp loop handling)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently the analyzer uses its widening_svalue and complexity limits on
svalues/regions to attempt to have the symbolic execution terminate due to
hitting already-visited nodes in the exploded_graph, but this doesn't work well
(see the various loop-related bugs here in bugzilla...)
Some ideas for improvement (not necessarily mutually exclusive):
(A) GCC's middle-end code already has code to analyze a CFG in gimple-SSA form
and determine a tree of nested loops, find iterator SSA names, loop bounds etc.
IIRC we're not currently making any use of this within -fanalyzer.
Maybe we should make use of it; for example, see bug 108432.
(B) Rework the program_point or supergraph code to have a notion of
* "1st iteration of loop",
* "2nd iteration of loop",
* "subsequent iterations",
or similar, so that the analyzer can explore those cases differently (on the
assumption that such symbolically executing such iterations precisely will
simulate the most interesting differences in behavior and thus help catch
bugs).
(C) Detect common patterns like:
for (int i = LOWER; i < UPPER; i++)
do_something_that_doesnt_touch (i)
and raises them to a higher-level representation, so that e.g.:
for (int i = LOWER; i < UPPER; i++)
arr[i] = 0;
gets raised to:
fill_arr(LOWER, UPPER, 0)
or somesuch
