Skip to content
This repository was archived by the owner on Jun 1, 2026. It is now read-only.

[WIP] add flow analysis framework experiment.#49

Draft
eddyb wants to merge 22 commits into
mainfrom
flow
Draft

[WIP] add flow analysis framework experiment.#49
eddyb wants to merge 22 commits into
mainfrom
flow

Conversation

@eddyb

@eddyb eddyb commented Oct 11, 2023

Copy link
Copy Markdown
Contributor

Based on #42 but I might make this one completely independent.

This needs a lot of improvements and documentation but I already sketched something so here it is:

right now it looks like this tower of abstractions (Capability/Object/ObjectState being new and scoped to the analysis, the rest are existing SPIR-T concepts):

  • Values (of pointer types)
    ⇊ which are approximated by/map to ⇊
  • Capabilitys (as in CHERI, or maybe "alias sets"?)
    ⇊ which point to (one or more) ⇊
  • Objects (as in C's "memory objects", aka "allocations")
    ⇊ which are flow-sensitively tracked as ⇊
  • ObjectStates (individual "versions" or "revisions" of object contents)
    ⇊ which describe changes by referring to ⇊
  • DataInsts (regular non-control-flow instructions, here qptr.{load,store})
    ⇊ which interface with the data they read/write as ⇊
  • Values (I lied, it's not a tower, it's an ouroboros)

but because this is based on small local steps put together, the interactions with Values would all admit applying e.g. constant folding and rewrite rules etc. (as long as everything can be undone - and only loops want the true "rubberbanding", to be able to fixpoint-saturate as many effects as possible to model the loop across its iterations, without actually accidentally interpreting the loop)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant