-
Notifications
You must be signed in to change notification settings - Fork 273
Make the simplifier preserve syntactically equal types [blocks: #2064] #3652
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
Make the simplifier preserve syntactically equal types [blocks: #2064] #3652
Conversation
4fa4741
to
12b6724
Compare
src/util/simplify_expr_int.cpp
Outdated
{ | ||
tmp.make_typecast(expr.type()); | ||
simplify_node(tmp); | ||
} |
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 one is potentially problematic, as the typecast is semantic, and does not necessarily preserve the bit-pattern.
I would refuse to do the simplification if the type differs.
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.
Ok, I’ll change this as suggested.
Note that this may create further type-inconsistency in the expression tree; say a symbol expression might now have a type that is not syntactically identical to the type it has elsewhere or in the symbol table. |
I get that, but I was hoping to be doing some good as this should support the other PRs that try to maintain types. Wouldn’t those suffer from the same issue? I’d happily use base_type_eq in the POSTCONDITION. (This PR is factored out from #2064, where the simplifier ended up returning completely unrelated types. I’d be happy to enforce semantic equivalence only.) |
@tautschnig I think the way to go is to get rid of base_type_eq and type_eq. This fixes the root cause of the issue. |
I.e., in the code in the PR, I'd replace the call to base_type_eq by expr.type() == expr.op().type(). There are a few places left where struct_tags get expanded (say the Java object factory). These should be fixed first. |
12b6724
to
3026a5d
Compare
I have added some commits that remove unnecessary expansion of types, but 1) the Java front-end still needs work, 2) this PR is getting too big so I've started factoring out individual commits, and 3) I've borrowed commits from other PRs. |
Remove unnecessary ns.follow in symex_dereference [blocks: #3652]
bugfix: symbol_factoryt must preserve struct_tag types [blocks: #3652]
Remove unnecessary use of ns.follow in flattening [blocks: #3652]
3026a5d
to
620edc2
Compare
bits2expr must return an expression of the requested type [blocks: #3652]
620edc2
to
c8e0866
Compare
c8e0866
to
9255f33
Compare
I have cleared out all the dependencies, this PR is now really just adding extra checks in the simplifier while not going as far as what's going to happen in #2064 (more work in the string solver is required as it currently makes use of some elaborate expressions within types). |
9255f33
to
2b0800d
Compare
When simplifying the operands of a concatenation permits replacing the concat expression by one of the (simplified) operands, only do so if that wouldn't result in a type mismatch.
Expression simplification should return an expression that is semantically equivalent. The type may only differ in moving from a tag to an expanded type or vice-versa, but the underlying types must always remain consistent.
2b0800d
to
450e568
Compare
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.
✔️
Passed Diffblue compatibility checks (cbmc commit: 450e568).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/98386718
base_type_eq guarantees semantic equality, but the resulting expression should
always have exactly the same type.