-
Notifications
You must be signed in to change notification settings - Fork 1.9k
C++: Generate side effect instructions for smart pointer indirections #5854
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
Conversation
This commit adds a `PrintAliasAnalysis.qll` module, which can be imported alongside `PrintIR.qll` to annotate those dumps with alias analysis results.
…`s on a memory access.
When inserting side effect instructions for argument indirections, we now insert side effects for smart pointers as we would for raw pointers. The address operand of the side effect instruction is the smart pointer object, which is a bit odd. However, I'd like to think through the design of a more principled solution before doing additional work. A few new tests are added to the existing IR tests. In addition, the IR tests now `#include` some of the shared STL headers. I've disabled IR dumps for functions from those headers, since they only get in the way of the test cases we intended.
| "SSA PrintAliasAnalysis": [ | ||
| "cpp/ql/src/semmle/code/cpp/ir/implementation/unaliased_ssa/internal/PrintAliasAnalysis.qll", | ||
| "cpp/ql/src/semmle/code/cpp/ir/implementation/aliased_ssa/internal/PrintAliasAnalysis.qll" | ||
| ], |
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.
Should the C# version be synced here?
MathiasVP
left a comment
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 (assuming Robert's comment is addressed).
|
It looks like we don't get a So I guess we need to use something other than I don't think any of this should block this PR, but we should think of a more robust way of doing this. |
|
I've started a CPP-differences here: |
I checked the performance on In the interest of preventing the PR from going stale, I think we should merge it as-is. I don't think any of the comments here are blocking this PR. What do you think @rdmarsh2? |
This PR is best reviewed commit-by-commit. It does introduce one consistency check failure, which I believe to be caused by an extractor problem that I'm trying to reduce to a simple repro.