analyzer: add -param=analyzer-max-constraints=
authorDavid Malcolm <dmalcolm@redhat.com>
Sun, 13 Sep 2020 23:35:28 +0000 (19:35 -0400)
committerDavid Malcolm <dmalcolm@redhat.com>
Mon, 14 Sep 2020 16:29:35 +0000 (12:29 -0400)
commit05ab8befe1230c46116aae37d44f2ce0933e8dae
treee1880cf165139311f135f54f0e722b66c86ef01b
parent799dd4e10047a4aa772fd69c910c5c6a96c36b9f
analyzer: add -param=analyzer-max-constraints=

On attempting to run the full test suite with -fanalyzer via
  make check RUNTESTFLAGS="-v -v --target_board=unix/-fanalyzer"
I saw it get stuck on:
  gcc.c-torture/compile/20001226-1.c
It turns out this was on a debug build, rather than a release build;
but a release build with -fanalyzer took:
  real 1m33.689s
  user 1m30.239s
  sys  0m2.727s
as compared to:
  real 0m2.361s
  user 0m2.107s
  sys  0m0.214s
without -fanalyzer.

This torture test performs 64 * 64 uniqely-coded comparisons between
elements of a pair of arrays until it finds an element that's different,
leading to an accumulation of 4096 constraints along the path where
no difference is found.

"perf" shows most of the time is spent in canonicalizing and copying
constraint_manager instances, presumably as it copies and merges states
with increasingly more complex sets of constraints as it analyzes
further along the "no differences yet" path.

This patch crudely works around this by adding a
  -param=analyzer-max-constraints=
limit, defaulting to 20, above which constraints will be silently
dropped.  With this -fanalyzer takes:
  real 0m6.935s
  user 0m6.413s
  sys  0m0.396s
on the above case.

gcc/analyzer/ChangeLog:
* analyzer.opt (-param=analyzer-max-constraints=): New param.
* constraint-manager.cc
(constraint_manager::add_constraint_internal): Silently reject
attempts to add constraints when the above limit is reached.
gcc/analyzer/analyzer.opt
gcc/analyzer/constraint-manager.cc