Skip to content

Conversation

@xavierleroy
Copy link
Contributor

Introduce a Num p abstract value that stands for any number (but no pointers), with provenance p. In non-strict mode, this makes the value analysis more precise than using Ifptr p for the same purpose, like we did before. (In particular, it should address the imprecision mentioned in #489, even though the vlub function remains non-monotonic.)

Also: minor simplifications and cleanups in the management of provenance. In strict mode, instead of setting all provenances to Pbot, just propagate them but ignore them in aptr_of_aval. Simplify vnormalize and its proof consequently.

Introduce a `Num p` abstract value that stands for any number (but no
pointers), with provenance `p`.  In non-strict mode, this makes the
value analysis more precise than using `Ifptr p` for the same purpose,
like we did before.

Also: minor simplifications and cleanups in the management of provenance.
In strict mode, instead of setting all provenances to `Pbot`, just
propagate them but ignore them in `aptr_of_aval`.  Simplify
`vnormalize` and its proof consequently.
@xavierleroy
Copy link
Contributor Author

NB. This will need to be run against AbsInt's test suite to check that it does not cause over-optimization.

@monniaux
Copy link
Contributor

Indeed, this allows, for instance, to establish that a stack variable and t[i], where t is an out-of-current-stackframe variable, are disjoint.

One possible case (Ptr, Num) and many impossible cases (e.g. I, F)
were sent to Vtop and are now given more precise upper bounds.
@xavierleroy
Copy link
Contributor Author

Testing shows no over-optimization. Merging.

@xavierleroy xavierleroy merged commit 8d5a9df into master May 25, 2023
@xavierleroy xavierleroy deleted the vanalysis branch May 25, 2023 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants