mirror of
https://github.com/FuelLabs/sway.git
synced 2025-08-08 04:38:19 +00:00
1c885cf0f1
## Description This PR adds an initial support to symbolic fuel-vm interpretation to improve codegen. The symbolic execution is designed to be extended in later PRs. In it's current form, it provides three distinct improvements: 1. If a temporary (allocated) register contains a value already held in another register, we can use that other register instead. This reduces register pressure, and removes unnecessary `mov` ops. 2. If a register already has the value we're setting it to, we can eliminate the instruction doing so. 3. For conditional jump instructions, if the value of the condition is known, one of the branches can be elminated. In such cases, the instruction is either removed or replaced with an unconditional jump. Dead code elimination pass can then potentially remove the now-unreachable branch. In addition to these changes, this PR takes the optimization level into account for asm generation. For debug builds, we only run the optimization passes once. But for release builds we run the optimization passes multiple times, until we either cannot eliminate any more operations, or until a fixed upper limit of rounds. For instance, this means that if the new pass added in this PR manages to eliminate a branch, and then dead code elimination removes that code, it could allow the interpretation pass to do even more work. To account for new optimization passes, I also organized them to mulple files, so that the ones which create private types are scoped well and thus easier to read. ## Impact project | size before | size after | size reduction -|-|-|- mira-v1-core | 89.384 KB | 83.480 KB | 6.6% ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). No changes required! - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. Just updated pre-existing ones! - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Vaivaswatha N <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
Forc
Forc stands for Fuel Orchestrator. Forc provides a variety of tools and commands for developers working with the Fuel ecosystem, such as scaffolding a new project, formatting, running scripts, deploying contracts, testing contracts, and more. If you're coming from a Rust background, forc is similar to cargo.
Find out everything you need to know about Forc under its chapter in the Sway book.