Skip to content

ModifierTrait#1008

Open
xeren wants to merge 10 commits intodevelopmentfrom
alias-modifiertrait
Open

ModifierTrait#1008
xeren wants to merge 10 commits intodevelopmentfrom
alias-modifiertrait

Conversation

@xeren
Copy link
Copy Markdown
Collaborator

@xeren xeren commented Mar 13, 2026

Adds more control over the used lattice in InclusionBasedPointerAnalysis. More implementations can be added later.

  • --program.analysis.alias=EXPERIMENTAL_FIELD_INSENSITIVE uses the singleton lattice $\lbrace\mathbb Z\rbrace$ implemented in ModifierTrait.VoidTrait. It lets the analysis be truely field-insensitive. It is not generally, but mainly, less precise than FIELD_INSENSITIVE implemented in AndersenAliasAnalysis.
  • --program.analysis.alias=EXPERIMENTAL_FIELD_SENSITIVE uses the lattice $\mathbb F(\mathbb Z)+\lbrace\mathbb Z\rbrace$ of finite sets. It is implemented in ModifierTrait.Offsets and comparable with FIELD_INSENSITIVE and FIELD_SENSITIVE.
  • --program.analysis.alias=EXPERIMENTAL_LINEAR_1D uses $\lbrace n+\mathbb Zs\mid n,s\in\mathbb Z\rbrace$ in ModifierTrait.SdLinear.
  • --program.analysis.alias=FULL remains using $\lbrace n+\sum_{i=0}^k\mathbb Zs_k\mid k\in\mathbb N,n,s_1,\ldots,s_k\in\mathbb Z\rbrace$ which has moved to ModifierTrait.MdLinear.

@ThomasHaas
Copy link
Copy Markdown
Collaborator

Interesting changes, but why the changes to the IntervalAnalysis? It was a deliberate choice to make it Optional.
Apart from the fact that those changes shouldn't be part of this PR in the first place :)

@xeren
Copy link
Copy Markdown
Collaborator Author

xeren commented Mar 13, 2026

You are right, this had nothing to do there.

@xeren xeren changed the title [Draft] ModifierTrait [DRAFT] ModifierTrait Mar 16, 2026
@ThomasHaas
Copy link
Copy Markdown
Collaborator

Do you intend to do more changes in this PR? It is marked as DRAFT after all :)

@xeren xeren changed the title [DRAFT] ModifierTrait ModifierTrait Apr 17, 2026
@xeren
Copy link
Copy Markdown
Collaborator Author

xeren commented Apr 17, 2026

I needed to add some unit tests before removing the [DRAFT] from this PR. Now that this is done, you can properly take a look at it.

Comment on lines +23 to +28
/// This method must not have false negatives, but is allowed to have false positives.
boolean overlaps(Modifier left, Modifier right);

/// Checks if for all integers `x` and `y`, `x[smaller]y` must imply `x[larger]y`.
/// This method must not have false positives, but is allowed to have false negatives.
boolean includes(Modifier larger, Modifier smaller);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you should include the approximation direction in the name of the methods:
mayOverlap(...) and mustInclude(...).

Comment on lines +54 to +58
/// Intersects `[modifier]` with `{ (x,y) | x <= y < x + objectSize }`.
/// If this intersection is empty, the associated access must be out-of-bounds.
/// <p>
/// This is an unsound strengthening that assumes no out-of-bounds accesses, given a memory object of known size.
Modifier postProcess(Modifier modifier, int objectSize);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description forces postProcess to have a very concrete semantics despite its very generic name. I would call it bound or restrict or something like that.

@ThomasHaas
Copy link
Copy Markdown
Collaborator

What is the correlation between the old alias analyses and the inclusion-based one with weaker modifier traits?
Do they coincide in terms of precision? What about computation time?

Also, do you think there are other reasonable instantiations of the ModifierTrait that could yield higher precisions? E.g., is the interface suitable to implement tracking of tagged pointers or is it too specialized to this kind of linear reasoning?

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.

2 participants