[cfe-dev] [StaticAnalyzer] Changing the loop widening functionality & measurements

[Gábor Horváth via cfe-dev]

Hi Péter!

On 28 August 2017 at 17:46, Péter Szécsi <peterszecsi95 at gmail.com> wrote:

> Hello everyone,
>
> I am working on loop modeling improvements in the Static Analyzer and sent
> recently some patches on loop widening. (D36690
> <https://reviews.llvm.org/D36690>)
> There is already a widening solution (widen-loops config) which
> invalidates every MemRegion in the process. My version only widen loops
> which meets specific requirements (e.g. does not contain any pointers). It
> is hidden behind a new flag 'widen-loops-conservative'. (It is conservative
> in the sense that it only widen specific loops.)
>
> In general case the difference of the 2 version is:
> widen-loops Invalidate everything
> widen-loops-conservative Only invalidate modified variables
>
> But a huge difference when there are pointers (most precisely if it
> encounters a statement which can result a modified variable but it is not
> handled yet):
> widen-loops Invalidate everything
> widen-loops-conservative Invalidate nothing (don't widen)
>
>
Just to bo clear, when you say you invalidate nothing, you mean to
terminate the analysis on that particular path right?
What would be the effect of turning on both options? Is that a valid
configuration?
E.g.: invalidating only modified variables when no pointer trickery is
involved is way better than invalidate everything. But if one would like to
maximize the coverage, it makes more sense to invalidate everything when
pointers are involved.



> I thought the new flag is necessary since this two options are very
> different. However, Sean (who created the current version of widening in
> D12358 <https://reviews.llvm.org/D12358>) suggested to replace the
> 'loop-widening' option with the new functionality. For considering this I
> collected the relevant statistics (note: the 'widen-loops' config
> encountered some crashes on C++ projects so the statistics are only
> collected on the files which has passed):
> *Widen *states for the current implementation*, Widen v2 *states for the
> new (D36690 <https://reviews.llvm.org/D36690>) implementation.
>
> Coverage measurements (% of reachable basic blocks statistics)
>
> curl libpng vim bitcoin ffmpeg xerces
> Normal 58.05 55.07 51.12 69.37 49.78 74.86
> Widen 75.8 56.69 51.54 72.06 65.63 76.06
> Widen v2 70.7 55.92 51.77 69.67 59.53 75.04
> The number of founded bugs:
>

I believe founded is a typo here, you might want to correct that before you
send this to the mailing list (in case that is your intention).


>
> curl libpng vim bitcoin ffmpeg xerces
> Normal 35 32 81 9 375 52
> Widen 35 36 94 12 456 57
> Widen v2 27 34 84 10 369 51
>
>
Why do you lose findings with Widen v2 but not with Widen? You widen fewer
loops in v2, so I would not expect it to use up the analysis budget more
often than the original version.


> The new findings are mostly resulted by the invalidation process and not
> the coverage increasement. So in general they are false positives which was
> founded by invalidating the informations (on MemRegions) we have.
>

What is the most frequent reson behind the false positives? Infeasible
execution paths or something else? This might be interesting, because in
the future we might add suppression heuristics to the most frequent cases.
E.g. suppressing findings on paths that are created when we split the
exploded graph as the result of the invalidation (e.g.: branching on a
value that is no longer known due to the invalidation).


>
> Although there is a small observable coverage loss it's offset by the
> number of the false positives not discovered.
>

Do you mean compared to widen?

In conclusion it would be beneficial to replace the current implementation
> of the 'widen-loops' option.
>
> What do you think?
>
> Cheers,
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170828/82d4505f/attachment.html>