This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Add limits to size of modeled data structures in environment.
ClosedPublic

Authored by ymandel on Feb 24 2022, 12:14 PM.

Details

Summary

Adds two new parameters to control the size of data structures modeled in the environment: # of values and depth of data structure. The environment already prevents creation of recursive data structures, but that was insufficient in practice. Very large structs still ground the analysis to a halt. These new parameters allow tuning the size more effectively.

In this patch, the parameters are set as internal constants. We leave to a future patch to make these proper model parameters.

Diff Detail

Event Timeline

ymandel created this revision.Feb 24 2022, 12:14 PM
ymandel requested review of this revision.Feb 24 2022, 12:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 24 2022, 12:14 PM
xazax.hun accepted this revision.Feb 24 2022, 12:27 PM

Very large structs still ground the analysis to a halt.

I had similar experience in the past with analyses that tried to represent all values in structs eagerly.

I think a better approach in general to make it as lazy as possible, so if a function does not access a field, never construct a representation for that in the memory.

This patch looks good and we will likely see the need for such limits even with a lazy system to handle certain code patterns. Are there any plans to make this more lazy in the future?

This revision is now accepted and ready to land.Feb 24 2022, 12:27 PM

Very large structs still ground the analysis to a halt.

I had similar experience in the past with analyses that tried to represent all values in structs eagerly.

I think a better approach in general to make it as lazy as possible, so if a function does not access a field, never construct a representation for that in the memory.

This patch looks good and we will likely see the need for such limits even with a lazy system to handle certain code patterns. Are there any plans to make this more lazy in the future?

Yes! Exactly as you mention, we're planning two approaches:

  1. Scan the AST of the function body and build the set of accessed fields. That will be consulted as a filter during construction.
  2. Support lazy construction. The problem we have is that we're not sure how to ensure that the "thunk" is shared between the "many worlds" that is the forking copies of the environments. We need to ensure that once the value is created lazily in one copy, it's visible in all others.
This revision was landed with ongoing or failed builds.Feb 24 2022, 12:52 PM
This revision was automatically updated to reflect the committed changes.