fixes instruction properties #1000
Merged
Conversation
This file contains hidden or 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
The instructions properties are computed from the semantics tags provided by a backend and from the BIL provided by a lifter. There was a bug the algorithm that was analyzing the BIL code, which, in particular, lead to a classification of a machine instruction as a barrier, when it wasn't. When the semantic tags were inferred from the BIL we didn't accumulate newly inferred tags to the list of existing ones but, instead, were overriding it. As a result, if an instruction contained more than one jump only the last jump was taken into account. This is a rare case, that was happening with the rep prefixed instructions (which had three) jumps with the latter being unconditional. Therefore such instructions were classified as barriers. First, we accumulate tags to make sure we won't override anything. Second, we hold an invariant that instruction can't possess both `Conditional_branch` and `Unconditional_branch` tags at the same time. That means that an instruction with a conditional jump will preserve this property, even in the presence of unconditional jumps. Going back to the rep prefixed instructions, they shouldn't be classified as jumps at all, and the right solution for them would be using the while statement (or repeat from the Core Theory), so that they will be classified as data having only data effects. But this is a story for a completely different PR
ivg
approved these changes
Oct 15, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The instructions properties are computed from the semantics tags
provided by a backend and from the BIL provided by a lifter.
There was a bug the algorithm that was analyzing the BIL code,
which, in particular, lead to a classification of a machine instruction
as a barrier, when it wasn't.
The essence of the bug
When the semantic tags were inferred from the BIL we didn't accumulate
newly inferred tags to the list of existing ones but, instead, were
overriding it. As a result, if an instruction contained more than one
jump only the last jump was taken into account. This is a rare case,
that was happening with the rep prefixed instructions (which had three)
jumps with the latter being unconditional.
Therefore such instructions were classified as barriers.
Solution
First, we accumulate tags to make sure we won't override anything.
Second, we hold an invariant that instruction can't possess both
Conditional_branchandUnconditional_branchtags at the same time.That means that an instruction with a conditional jump will preserve this
property, even in the presence of unconditional jumps.
Better solution
Going back to the rep prefixed instructions, they shouldn't be
classified as jumps at all, and the right solution for them would be
using the while statement (or repeat from the Core Theory), so that
they will be classified as data having only data effects.
But this is a story for a completely different PR