implied: very messy re-write of how to bail if implications are taking too long
commita86c10b1446e7ea0c791ef6fbc7a39b124916003
authorDan Carpenter <dan.carpenter@oracle.com>
Tue, 26 Feb 2019 19:07:12 +0000 (26 22:07 +0300)
committerDan Carpenter <dan.carpenter@oracle.com>
Tue, 26 Feb 2019 19:07:12 +0000 (26 22:07 +0300)
tree63ef4bd11674298240e12321610a20f7a511c3b4
parent302ca037b607731790def8b6e8d67513f5e7cf28
implied: very messy re-write of how to bail if implications are taking too long

There are several methods that Smatch uses to know when to bail.  Some of
them are going to be deleted soon.  I'm trying to move to a time based
system for giving up.

There are several considerations:

1)  We allow 1 second to determine which strees are true and which are
    false.  If we haven't finished, then we use what we know.

2)  We allow 3 seconds total to apply those results to the cur_stree.  We
    do this in order of the ->owner ID so smatch_extra is near the start.
    We used to allow 5 seconds per sm_state which is crazy and too much.
    Keep in mind that if we spend too long figuring out these implications
    then we have to sacrifice the time from something else.  So now it is
    3 seconds for all the sm states.

3)  Some individual states take too long to apply.  For this, we use the
    "*recurse" parameter.  I've changed this from 1000 to 250.  My
    intuition says that 1000 is too high.

     We used to use ->skip_implications and ->nr_children to cap this.

     The problem is that the ->nr_children count was always wrong, insanely
     high and useless.  I think maybe it was because when we're figuring
     out implications then things get re-parented.

     The ->skip_implications flag seems like it could be a good idea, but
     it was applied to the recursed sm far down in the tree so we may as
     well just use the recurse count.  It would be simple enought to mark
     the parent as ->skip_implications but that requires some more thought,
     and testing and I'm not totally positive it is even required.

4)    Then in filter_stack() if the time is up, just return with what you
      have.  If the recurse count is too high, that returns a NULL so just
      continue to the next sm.

This is all sort of functional, but this patch is crazy ugly.  I will
clean it up soon.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch_implied.c