-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
C++: Support IRGuard
s with no implicit boolean conversion
#16364
Conversation
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.
Two small comments.
Co-authored-by: Jeroen Ketema <[email protected]>
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.
LGTM, and DCA looks clean.
// value.(BooleanValue).getValue() = true | ||
// ``` | ||
// but all we know is that the value is non-zero in the true branch. | ||
// So we can only conclude something in the false branch. |
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.
What would be the consequences if we included common values for true
(namely 1
and -1
)? Would any results be wrong, or just incomplete?
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.
Results would be wrong. For example, consider this example:
void foo(char* p) {
if(p) { // assume we uncommented the above so that we inferred that `p == 1` is implied by this
if(p == 1) { // I know this is a weird comparison to do on a pointer, but oh well.
// We would conclude that this branch was always taken
}
}
}
When this is compiled as C code:
there's no implicit conversion to boolean, and thus we don't generate a
CompareInstruction
that theIRGuards
library rely on.This PR adds a case to
IRGuards
so that we can also infer guards when noCompareInstruction
s are present in the condition