Skip to content

Update Core's evaluator do symbolic execution only without partial evaluation#921

Merged
shigoel merged 17 commits intomainfrom
jlee/parteval-fix
Apr 16, 2026
Merged

Update Core's evaluator do symbolic execution only without partial evaluation#921
shigoel merged 17 commits intomainfrom
jlee/parteval-fix

Conversation

@aqjune-aws
Copy link
Copy Markdown
Contributor

@aqjune-aws aqjune-aws commented Apr 15, 2026

Strata's Core evaluator is truly a partially evaluator in the sense that it can simplify the given program for every possible execution path, and returns portfolio of simplified programs. It means that there are N diverging control flows in a program, it can return N different programs.
However, this can cause certain benchmarks' memory usage of Strata increase quickly to maintain a set of variants of programs after partial evaluation. I think that without explicitly keeping the partially evaluated programs Strata will still simplify symbolic expressions pretty well and the ultimate verification conditions will virtually look the same. It is because partial evaluator not only returns the partially evaluated programs, but also the symbolic environment after executing the program. The symbolic environment will already contain path conditions and proof obligations - these are independent from the partially evaluated program. The benchmark seems unregressed after this change.

This patch renames Core.typeCheckAndPartialEval to Core.typeCheckAndEval, and its underlying partial evaluators to purely do symbolic simulations only. :)


CLARIFICATION: The Lambda's evaluator will still remain as a partial evaluator, as it wasn't designed to diverge into multpiple different evaluation results for now


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@aqjune-aws aqjune-aws requested a review from a team April 15, 2026 04:53
Comment thread Strata/Languages/Core/ProgramEval.lean Outdated
Comment thread StrataTest/Languages/Core/Examples/BitVecParse.lean Outdated
@MikaelMayer
Copy link
Copy Markdown
Contributor

I would love to see how this PR could be influenced by or influence this other PR I'm working on:
#753
Do you have any insights?

Comment thread Strata/Languages/Core/StatementEval.lean Outdated
Comment thread Strata/Languages/Core/ProcedureEval.lean
Comment thread Strata/Languages/Core/StatementEval.lean
Comment thread Strata/Languages/Core/StatementEval.lean Outdated
Copy link
Copy Markdown
Contributor

@MikaelMayer MikaelMayer left a comment

Choose a reason for hiding this comment

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

Clean simplification that removes the partial-evaluation output (transformed programs) from the evaluator, keeping only the symbolic environments. The core idea is sound: the proof obligations and path conditions already live in the Env, so carrying the rewritten program through the pipeline was unnecessary overhead.

A few items to address:

  1. Bug — missed rename in Strata/MetaVerifier.lean: genVCs (line 60) still calls Core.typeCheckAndPartialEval, which was renamed to Core.typeCheckAndEval. This will fail to compile.

  2. Dead code — StmtsStack in StatementEval.lean: The StmtsStack type alias and its four methods (push, pop, top, appendToTop, lines 371–389) are no longer referenced after removing the stk field from EnvWithNext. They should be removed.

  3. See inline comments for two smaller nits.

Comment thread Strata/Languages/Core/StatementEval.lean Outdated
Comment thread Strata/Languages/Core/StatementEval.lean Outdated
@MikaelMayer
Copy link
Copy Markdown
Contributor

@keyboardDrummer-bot can you please look at this comment
#921 (comment)
And do an analysis of the two PRs to see how they overlap, complement each other, or may influence each other?

@aqjune-aws
Copy link
Copy Markdown
Contributor Author

I would love to see how this PR could be influenced by or influence this other PR I'm working on: #753 Do you have any insights?

I think in high level it goes well with #753 (even if it might have some merge conflicts), because the direction is towards simplifying the PE engine and factoring out program-transforming logics to program transformations. Every transformation that is newly defined in #753 will still be valid ones.

@aqjune-aws
Copy link
Copy Markdown
Contributor Author

Addressed comments

@aqjune-aws aqjune-aws removed their assignment Apr 15, 2026
@shigoel shigoel enabled auto-merge April 15, 2026 23:49
shigoel
shigoel previously approved these changes Apr 15, 2026
Comment thread Strata/DL/Imperative/CmdEval.lean Outdated
Comment thread Strata/Languages/Core/ProgramEval.lean
Comment thread Strata/Languages/Core/ProgramEval.lean Outdated
Comment thread Strata/Languages/Core/StatementEval.lean Outdated
Comment thread Strata/Languages/Core/Core.lean Outdated
@shigoel shigoel added this pull request to the merge queue Apr 16, 2026
Merged via the queue into main with commit 3064098 Apr 16, 2026
17 checks passed
@shigoel shigoel deleted the jlee/parteval-fix branch April 16, 2026 19:08
MikaelMayer added a commit that referenced this pull request Apr 16, 2026
…ould-b

Main PR #921 changed the evaluator to do symbolic execution only (no PE).
This removed the stk mechanism that built transformed programs, making the
branch's ObligationExtraction and Deduplication incompatible.

Resolve by reverting to main's evaluator and test outputs. The
ObligationExtraction and Deduplication modules remain in the codebase
but are not wired into the pipeline. Remove PEAssumeTest which tested
PE-specific behavior that no longer exists.
MikaelMayer added a commit that referenced this pull request Apr 17, 2026
Rename Deduplication.lean to ANFEncoder.lean and update all identifiers
(deduplicateProgram -> anfEncodeProgram, etc.) to clarify this is the
same concept as the SMT-level ANF encoder but operating on Core programs.

ObligationExtraction and ANFEncoder are not yet wired into the pipeline
because main's evaluator (#921) does symbolic execution without producing
a transformed program. These modules will be integrated once the evaluator
produces a program that ObligationExtraction can walk.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants