wip: support non-indexed bit rotate where possible - #303
Draft
xeniarose wants to merge 1 commit into
Draft
Conversation
xeniarose
marked this pull request as draft
June 25, 2026 20:46
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.
This implements non-indexed bit rotation operations (i.e., where the amount to rotate by can be symbolic) for all solvers that support it (Z3, Bitwuzla), and falls back to the current behavior which reduces the bit rotates to bit shifts for all other solvers. See issue: #302
While Boolector nominally supports
ext_rotate_{left,right}, I found that it segfaults when given SMT-LIB input containing these operations. It's unlikely that's going to ever be fixed, so the Boolector solver still uses the reduction to bit shifts.Description of the changes:
bvrorandbvrolto their own operation typesext_rotateto solvers that support a bit rotation extensionsolver-custom-encodemethod togen:solverwhich is threaded throughencand called whenencdoesn't know how to encode something.base-solverlowers@bvroland@bvrorto bit shifts by default. Solvers with a bit rotation extension override the method to output their appropriate extension syntax. If neitherencnor the solver know how to encode something, it still raises the same error as before.ext_rotate_{left,right}andbvro{l,r}). These are hardcoded (instead of using a newgen:solvermethod as above), since the same decoding behavior works for all solvers.I ran the test suite with all the available solvers on my computer. The generic tests are passing, and the following solvers are working: Z3 (bundled version, 4.8.8), CVC4 (1.8), CVC5 (1.3.4), Bitwuzla (0.9.0), Boolector (3.2.4), Yices (2.7.0)
STP (2.3.4) tests are failing even on the current main branch (29808a0), so I'm unable to test with it. If there's a specific known working version of STP I can run the tests with that version.
I'm happy to make any required changes if a different implementation is desired or other fixes are needed