zero extension expression #8442
Open
Conversation
This file contains 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
Member
kroening
commented
Sep 5, 2024
kroening
commented
- Each commit message has a non-empty body, explaining why the change was made.
- Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
- n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
- Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
- My commit message includes data points confirming performance improvements (if claimed).
- My PR is restricted to a single feature or bugfix.
- n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.
kroening
force-pushed
the
zero_extend
branch
from
70aec8f
to
fc73983
Compare
kroening
requested review from
martin-cs,
peterschrammel,
TGWDB and
tautschnig
as code owners
kroening
force-pushed
the
zero_extend
branch
from
fc73983
to
716dfc8
Compare
This adds ::zero_expr() and ::one_expr() for integers, natural numbers, rationals and reals.
kroening
force-pushed
the
zero_extend
branch
from
716dfc8
to
e77bbe3
Compare
tautschnig
approved these changes
Sep 5, 2024
kroening
force-pushed
the
zero_extend
branch
from
e77bbe3
to
20acf16
Compare
This introduces the zero_extend expression, which, given a bit-vector operand and a type, either a) pads the given operand with zeros from the left if the given type is wider than the type of the operand, or b) truncates the operand to the width of the given type if the given type is smaller than the operand, or c) reinterprets the operand as having the given type if the width of the type and the width of the operand match. This may differ from conversion if the types have different bit representations. This is easier to read and less prone to error than the current pattern, in which the operand is 1) converted to an unsigned type of the same width, and then 2) casted to an unsigned type of the wider width, and 3) finally casted to the target type.
kroening
force-pushed
the
zero_extend
branch
from
20acf16
to
2b09504
Compare
I believe this is actually a necessary feature for unit tests to pass. |
|
I think the support for zero_extend should be added to the simplifier before merging. Moving from expressions which are supported by the simplifier to a new one which is not may have a performance cost. |
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.