Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zero extension expression #8442

Merged
merged 1 commit into from
Nov 1, 2024
Merged

zero extension expression #8442

merged 1 commit into from
Nov 1, 2024

Conversation

kroening
Copy link
Member

@kroening kroening commented Sep 5, 2024

  • 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.

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

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

I would be nice to see support in the simplifier for any case that does zero_extend of a constant.

@tautschnig
Copy link
Collaborator

I would be nice to see support in the simplifier for any case that does zero_extend of a constant.

I believe this is actually a necessary feature for unit tests to pass.

@thomasspriggs
Copy link
Collaborator

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.

@kroening
Copy link
Member Author

kroening commented Oct 3, 2024

Now with simplifier support.

Copy link

codecov bot commented Oct 3, 2024

Codecov Report

Attention: Patch coverage is 77.96610% with 13 lines in your changes missing coverage. Please review.

Please upload report for BASE (develop@20a1ecf). Learn more about missing BASE report.
Report is 2 commits behind head on develop.

Files with missing lines Patch % Lines
src/util/bitvector_expr.cpp 66.66% 3 Missing ⚠️
src/util/format_expr.cpp 40.00% 3 Missing ⚠️
...c/solvers/smt2_incremental/convert_expr_to_smt.cpp 0.00% 2 Missing ⚠️
src/util/simplify_expr_int.cpp 66.66% 2 Missing ⚠️
src/solvers/flattening/boolbv.cpp 50.00% 1 Missing ⚠️
src/solvers/floatbv/float_bv.cpp 80.00% 1 Missing ⚠️
...ncremental/smt2_incremental_decision_procedure.cpp 85.71% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             develop    #8442   +/-   ##
==========================================
  Coverage           ?   78.88%           
==========================================
  Files              ?     1727           
  Lines              ?   198398           
  Branches           ?    18545           
==========================================
  Hits               ?   156504           
  Misses             ?    41894           
  Partials           ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

}
else // new_width <= old_width
{
return extractbits_exprt{op(), integer_typet{}.zero_expr(), type()};
Copy link
Member

Choose a reason for hiding this comment

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

Isn't the index argument a sizet?

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.
Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

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

Looks good.

@kroening kroening merged commit 8fcd9b1 into develop Nov 1, 2024
38 of 39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants