Repository navigation
Reuse instruction-flow lift storage within each decoding worker - #1613
Merged
Merged
Conversation
…n-flow-storage Dev's unsized-body reader and call graph decode through decodeFunctions. Both now take the decoding worker's InstructionFlowScratch, so they build against the four-argument visitor and reuse the same lift storage.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Full-image reference and access-width sweeps constructed and released a LowOp vector for each instruction. Give each decoding worker a private scratch vector and reuse only its capacity across instructions. Disassembly pages use a call-local workspace; reference, string-reference and width scans use the same summarizer.
Every instruction still clears operations and resets x87 state, including after an unsupported lift. Results own their references and transfer facts. There is no shared mutable scratch, TLS cache, smaller scan scope or unsupported-instruction shortcut.
The SDK regression uses independent load/NOP/return and store/NOP/return sequences: trailing instructions must not inherit references, repeated reads must agree, and conflicting access widths remain unknown. A real CLI/worker test generates two-function and multi-page ELF fixtures, checks every reference against the encoded instruction addresses, and verifies 4/8-byte widths and complete pagination. It needs no external binary or fixture compiler.
Before rebasing onto current dev, three paired Windows Release SDK runs with the reusable-page-index baseline reduced first source preparation by about 24%. A single GUI pair improved about 16%; it is recorded as a single observation, not a stable distribution. Input identities, binaries, hashes and raw logs are omitted.
Windows x64 Release: 11 focused SDK cases passed without skips. The registered NeverDWorkerCLIInstructionFlow test passed with freshly linked CLI/worker products, including both synthetic inventory sizes, repeated CLI reads and complete worker paging. The modified C++ ranges and diff whitespace were checked. Full CTest and native Linux/macOS host runs were not performed locally. This PR targets dev independently of the address-order cache and applies to the shared SDK used by CLI and GUI.