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>