Skip to content

Byte extract lowering for vectors and array cleanup [blocks: #2068, #4187] #4124

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

Merged
merged 5 commits into from
Feb 14, 2019

Conversation

tautschnig
Copy link
Collaborator

Only the last three commits are new, the rest is borrowed from #4123.

  • 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).
  • n/a 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
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: c21e390).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100140199

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: f62cfae).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100907943

@tautschnig tautschnig changed the title Byte extract lowering for vectors and array cleanup [depends-on: #4123, blocks: #2068] Byte extract lowering for vectors and array cleanup [blocks: #2068, #4187] Feb 14, 2019
@tautschnig tautschnig force-pushed the byte-op-5 branch 2 times, most recently from ff981ee to 8836523 Compare February 14, 2019 13:07
@tautschnig
Copy link
Collaborator Author

@smowton All comments addressed.

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: 8836523).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100944534

Copy link
Contributor

@smowton smowton 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, thanks! One comment I think is wrong and a tiny nitpick -- one other thing: can we avoid the back-and-forth between constant_exprt and optional<mp_integer> that happens when we recurse into a member? That seems a little error-prone, as well as expensive.

@@ -111,7 +111,7 @@ static array_exprt unpack_array_vector(
// recursively unpack each element until so that we eventually just have an
// array of bytes left
exprt sub =
unpack_rec(element, little_endian, nil_exprt(), max_bytes, ns, true);
unpack_rec(element, little_endian, nullopt, max_bytes, ns, true);
Copy link
Contributor

Choose a reason for hiding this comment

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

Usually {} rather than nullopt

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We seem to have a small number of uses, but agreed that {} is more common and thus to be used.

Refactor the code used for arrays to make it re-usable for vectors and arrays.
We already limited extraction at an uppper bound, but when we know the offset we
can also start as late as possible. For structs, for example, we now do not
expand components that will be irrelevant to the final result.
No need to construct index_exprt when we can just pick the operand out of a
vector.
This makes the unit of measurement explicit and thus should help avoid
bits/bytes confusion.
This makes the interface much more explicit about what is or isn't supported at
moment.
@tautschnig
Copy link
Collaborator Author

can we avoid the back-and-forth between constant_exprt and optional<mp_integer> that happens when we recurse into a member? That seems a little error-prone, as well as expensive.

Using optionalt<mp_integer> makes things again much simpler :-) - thanks!

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: bd30790).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100967585

@tautschnig tautschnig merged commit e654aa7 into diffblue:develop Feb 14, 2019
@tautschnig tautschnig deleted the byte-op-5 branch February 14, 2019 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants