================
@@ -2515,9 +2518,13 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
BeforeProcessingCall->getLocationContext(), CE, nullptr, &PT);
// Add the special flag to GDM to signal retrying with no inlining.
// Note, changing the state ensures that we are not going to cache out.
+ // NOTE: This stores the call site (CE) in the state trait, but only the
+ // the actual pointer value is only checked by an assertion; for the analysis
+ // only the presence or absence of this trait matters.
+ // FIXME: I suspect that CE may be a nullpointer, which will be interpreted
+ // as the absence of this state trait (and does not prevent caching out).
----------------
NagyDonat wrote:
> I don't think we are ready for getting rid of the blocklist. We would need to
> supplement it somehow to carefully avoid regressing the analysis time.
> Remember, this was put in place to avoid some corner-cases. We can't just
> drop this.
Yes, I know that removing the blocklist would be very difficult. In fact, I
observed that it is not just for corner cases, it is a significant factor in
the average analysis time as well.
However I'm overall very unsatisfied by the fact that the analysis time is
governed by accidentally evolved, opaque and chaotic processes. My intuition is
that (with the default settings) the overall budget is only reached is a small
minority of entrypoints, so it is only a secondary factor in determining the
runtime.
To address these I'm brewing vague plans for an eventual redesign that would
make the runtime more "balanced" and transparently controllable by the user.
The first step would be setting up an environment for better runtime
measurements, where we can analyze real-world projects and collect detailed
statistics about the effects of various factors on the runtime -- after that I
hope that I can propose better heuristics.
Obviously, I don't want to surprise users with sudden changes of the analysis
time, so the new time control settings would be "off by default". (At least
initially – if many users try and prefer it, I would probably put a deprecation
warning on the old heuristics, then in a later version switch to the new
setting by default, then later eventually remove the old heuristics.)
https://github.com/llvm/llvm-project/pull/188319
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
