xazax.hun added a comment. In D142710#4096325 <https://reviews.llvm.org/D142710#4096325>, @ymandel wrote:
> In D142710#4094934 <https://reviews.llvm.org/D142710#4094934>, @xazax.hun > wrote: > >> This change looks good to me. I wonder, however, whether the behavior should >> be parameterized in the future. E.g., whether the user of the analysis >> should be able to make a decision whether the analysis should be pessimistic >> or optimistic about unmodeled values. > > Interesting idea. I think this goes along with other places where we are > unsound. Here, we err on the side of soundness. but, in general, we should > have a configuration mechanism for this. FWIW, the only reason we have > uninitialized values at this point is recursive types. We also limit the > depth of structs, but that should be removed given my recent patch to only > model relevant fields. I have an idea for lazy initialization of values that > I think could solve the recursion issue. Together, we could remove this > concept of unmodeled values altogether from the framework. Oh, sounds great! I do think lazy initialization will be really valuable to reduce the number of unmodeled values, but not entirely sure if we can completely eliminate them. In case we end up creating new locations (different from the earlier ones) in every iteration of the loop it might be harder to reach a fixed point. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142710/new/ https://reviews.llvm.org/D142710 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
