This is an archive of the discontinued LLVM Phabricator instance.

[Static Analyzer] Small array binding policy
ClosedPublic

Authored by isuckatcs on Jun 17 2022, 8:26 AM.

Details

Summary

If a lazyCompoundVal to a struct is bound to the store, there is a policy which decides
whether a copy gets created instead.

This patch introduces a similar policy for arrays, which is required to model structured
binding to arrays without false negatives.

Diff Detail

Event Timeline

isuckatcs created this revision.Jun 17 2022, 8:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 17 2022, 8:26 AM
isuckatcs requested review of this revision.Jun 17 2022, 8:26 AM
xazax.hun accepted this revision.EditedJun 17 2022, 9:33 AM

Overall, the code looks good. I am a bit unsure about the default limit though. If someone already did the math that 2 is the sweet spot for structs would that mean we should lower this value for arrays? This is something that is easy to change/tune in the future, so I think it might be ok to commit as is.

This revision is now accepted and ready to land.Jun 17 2022, 9:33 AM

I think the sweet spot is between 3-5 somewhere. This number also corresponds to the size of the array which we can model without false negatives.

As for use cases I can think about having coordinates, color values, or similar related values stored in an array, where it makes sense to create a
named binding to each element. Most of these cases consist of at most 4 elements. I set the limit to 5 just in case one more binding must be
created.

Because we have another patch depending on this one, I'm going to merge it, and if 5 seems to be a too large number, we can tune it later as
you mentioned.

This revision was landed with ongoing or failed builds.Jun 17 2022, 9:56 AM
This revision was automatically updated to reflect the committed changes.
NoQ added a comment.Jun 17 2022, 5:01 PM

Another magic number around these parts is 4, which is our loop iteration budget. If an array is initialized by a loop with unknown bounds, it'll have 4 bindings. So I think it makes sense to reduce the default to 4 just because weird things may start happening above this threshold.

What's out desired approach for that? Create a new patch, or update this one? Also, should I commit it as usual, or revert this commit first?

NoQ added a comment.Jun 18 2022, 12:43 PM

There's nothing immediately wrong with this patch so no need to revert it. It makes sense to revert a patch if it breaks buildbots or if there's no fix coming soon (eg. if we're about to have an entire LLVM release broken). If there was a revert it would have made sense to reuse the phabricator revision as well. But as it is, just make a new patch :-)

No need for post commit fixes, just general observations since I noticed them.

clang/lib/StaticAnalyzer/Core/RegionStore.cpp
2427

Unless we use this a lot, it'd be better to just use AnalyzerOptions natively, it'd be more visible that this is directly configurable by the user.

There is no need to change this once its here, just a general design observation.

2466

For SVal::getAs, we usually use auto for the return value type (which has its history: D54877#inline-484319!).