Skip to content

C++: No more flow into ReadSideEffect instructions #4393

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 8 commits into from
Oct 5, 2020

Conversation

MathiasVP
Copy link
Contributor

@MathiasVP MathiasVP commented Oct 2, 2020

#3123 (comment) pointed out its weird to have flow into ReadSideEffectInstruction as that instruction has no return value, and that it gives confusing path explanations.

Now that we have operands as dataflow nodes we can avoid this rule and wire flow directly from the definition of the memory operand instead of going through the ReadSideEffectInstruction.

CPP-difference shows no performance problems.

@MathiasVP MathiasVP added the C++ label Oct 2, 2020
@MathiasVP MathiasVP requested a review from a team as a code owner October 2, 2020 12:17
@MathiasVP MathiasVP added the depends on internal PR This PR should only be merged in sync with an internal Semmle PR label Oct 2, 2020
@MathiasVP
Copy link
Contributor Author

This PR should be good to go. The remaining changes are accepted in the internal PR.

- ArgumentNode is now abstract
- PrimaryArgumentNode is now an OperandNode.
- ArgumentIndirectionNode is now merged into SideEffectArgumentNode.
jbj
jbj previously approved these changes Oct 5, 2020
Comment on lines 146 to 145
| test.cpp:235:11:235:20 | (size_t)... | semmle.label | (size_t)... |
| test.cpp:237:10:237:19 | (size_t)... | semmle.label | (size_t)... |
| test.cpp:235:2:235:9 | Arg(0) | semmle.label | Arg(0) |
| test.cpp:237:2:237:8 | Arg(0) | semmle.label | Arg(0) |
Copy link
Contributor

Choose a reason for hiding this comment

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

These toStrings were not very pretty before, and they're not very pretty now. But at least now we have the ability to override their toString in the future because we've separated the argument from the instruction that produces it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just noticed this as well and pushed a better toString. Originally, I had planned on adding this in a future PR, but I couldn't accept these ugly path explanations we got without a specialized toString.

@jbj jbj merged commit 6b2ae5d into github:main Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C++ depends on internal PR This PR should only be merged in sync with an internal Semmle PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants