Skip to content
Snippets Groups Projects

Def use, dataflow, typechecking, structural verification, IR and DESIGN.md updates

Merged Def use, dataflow, typechecking, structural verification, IR and DESIGN.md updates
ir_dev into main
1 unresolved thread
Merged rarbore2 requested to merge ir_dev into main
1 unresolved thread
  • Add def use analysis, creates compact immutable def use map
  • Add reverse postorder and dataflow analysis - computes a generic dataflow analysis over an arbitrary lattice
  • Typecheck whole IR
  • Verify IR structure (verify projections mostly)
  • Add extractsum
  • Update DESIGN.md

Merge request reports

Checking pipeline status.

Approved by
Aaron Councilman

Merged by rarbore2rarbore2 1 year ago (Sep 29, 2023 12:44am UTC)

Merge details

  • Changes merged into main with 774b58d3 (commits were squashed).
  • Deleted the source branch.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
hercules_ir/src/dataflow.rs 0 → 100644
12 fn meet(a: &Self, b: &Self) -> Self;
13 fn bottom() -> Self;
14 fn top() -> Self;
15 }
16
17 /*
18 * Top level dataflow function. This routine is slightly more generic than the
19 * typical textbook definition. The flow function takes an ordered slice of
20 * predecessor lattice values, rather than a single lattice value. Thus, the
21 * flow function can perform non-associative and non-commutative operations on
22 * the "in" lattice values. This makes this routine more useful for some
23 * analyses, such as typechecking. To perform the typical behavior, the flow
24 * function should start by meeting the input lattice values into a single
25 * lattice value.
26 */
27 pub fn dataflow<L, F>(
  • Aaron Councilman
    Aaron Councilman @aaronjc4 ·
    Owner

    Could we need (in the future, if not now) a backwards dataflow analysis framework, and if so should we name this to indicate that it is a forwards dataflow problem? Or, since the two procedures are mostly the same, could they be merged into a single implementation?

  • rarbore2
    rarbore2 @rarbore2 ·
    Author Maintainer

    So a backwards dataflow would use ImmutableDefUseMap to look at users of a node, rather than NodeUses to look at predecessors of a node. This would imply that the code would need to be changed to support that. I will rename to forward_dataflow.

  • rarbore2 changed this line in version 3 of the diff

    changed this line in version 3 of the diff

  • Please register or sign in to reply
  • Aaron Councilman
    Aaron Councilman @aaronjc4 ·
    Owner

    Looks good to me. I left one comment about whether we should add a backwards dataflow analysis framework, or at least name things to allow for one to be added without too many changes.

  • Aaron Councilman approved this merge request

    approved this merge request

  • rarbore2 added 1 commit

    added 1 commit

    • d80d1cf9 - Rename dataflow to forward_dataflow

    Compare with previous version

  • rarbore2 mentioned in commit 774b58d3

    mentioned in commit 774b58d3

  • rarbore2 merged

    merged

    • Please register or sign in to reply