-
Notifications
You must be signed in to change notification settings - Fork 63
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
Heapster/exponential code explosion #1528
Conversation
…arious cases more clear
…s that could actually be used to prove a permission at the given offset
… its own SAW core definition, rather than having the entire global be copied into each spec when it is used
…an OpenTerm after it is completed
…ion translation, to avoid exponential code explosion
…ings for repeated terms; added a type ascription term to the Coq AST; changed the translation of the unit type to give it an explicit ascription to sort Type rather than Set
…es' into heapster/sha512
Oops, and this PR also changes how |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks awesome, thanks Eddy!
This PR addresses the problem of exponential explosion during code generation, by inserting let-bindings for the outputs of each
TypedSetReg
operation. This prevents Crucible code likex2 = x1+x1; x3 = x2+x2; ...
from generated exponential-sized expressions in the generated Coq.
This PR also makes two other changes:
LLVM globals now generate SAW core definitions, so that their specifications are not copied each time they are used in a program
A simple translation of
BVUndef
was defined, that translates these poison values to the bitvector value 0, though this should probably be readdressed in the future