Skip to content

C++: Synchronize product dataflow paths on function entry points #12997

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 4 commits into from
May 4, 2023

Conversation

MathiasVP
Copy link
Contributor

@MathiasVP MathiasVP commented May 2, 2023

The experimental "product dataflow library" already synchronizes the two paths when the enclosing callable changes, but the synchronization point didn't check that we entered through the same call. This gave FPs such as the one I added in #12989.

This PR fixes this class of FPs by checking that we entered through the same function call whenever we flow into a function. Similarly, we check that we leave through the same function call in the two paths.

@MathiasVP MathiasVP requested a review from a team as a code owner May 2, 2023 16:03
@github-actions github-actions bot added the C++ label May 2, 2023
@MathiasVP MathiasVP force-pushed the sync-product-flow-across-calls branch from d1ac07b to 7fa6894 Compare May 2, 2023 16:13
Comment on lines 382 to 384
kind = TOutOf(call) and
succ1.getNode().(OutNode).getCall() = call and
pred1.getNode() instanceof ReturnNode
Copy link
Contributor

Choose a reason for hiding this comment

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

There can be other out-flow besides the OutNode-to-ReturnNode pairs. It can also be from a PostUpdateNode that has flow from a parameter to a PostUpdateNode for an argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, yes. That's a good point. I decided to blatantly ignore jump steps for now, but the PostUpdateNode -> PostUpdateNode flow caused by setter-like functions is probably too frequent of an occurrence to be ignored.

Copy link
Contributor

Choose a reason for hiding this comment

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

You can probably account for jump-steps by having a kind "jump" and identify that as an interproc edge that's not in one of the other cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea. Hopefully I've done this in 0d6fdc6 🤞.

@MathiasVP
Copy link
Contributor Author

DCA confirms that the performance has been fixed by d3d706d 🎉

jketema
jketema previously approved these changes May 4, 2023
Copy link
Contributor

@jketema jketema left a comment

Choose a reason for hiding this comment

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

LGTM. I don't know if @aschackmull has any further comments?

Copy link
Contributor

@aschackmull aschackmull left a comment

Choose a reason for hiding this comment

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

Doesn't work yet.

Comment on lines 364 to 366
TOutOf(DataFlowCall call) {
[any(Flow1::PathNode n).getNode(), any(Flow2::PathNode n).getNode()].(OutNode).getCall() =
call
Copy link
Contributor

Choose a reason for hiding this comment

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

This is too restrictive for the post-update out-flow to work.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, you're right. Will fix (and rerun DCA)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should hopefully be fixed by 26206a8 🤞

@jketema
Copy link
Contributor

jketema commented May 4, 2023

Doesn't work yet.

Glad I asked 😄

Comment on lines +360 to +365
intoImpl1(_, _, call) or
intoImpl2(_, _, call)
} or
TOutOf(DataFlowCall call) {
outImpl1(_, _, call) or
outImpl2(_, _, call)
Copy link
Contributor

@aschackmull aschackmull May 4, 2023

Choose a reason for hiding this comment

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

Looks fine now. If you want, you can change these two disjunctions into conjunctions for a little bit of earlier filtering - might as well once it's written this way.

Copy link
Contributor

@aschackmull aschackmull May 4, 2023

Choose a reason for hiding this comment

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

Ah, wait, no, scratch that - then the jumps won't be identified correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Uh, that's clever! Will do that

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, yes... that's true. I guess I won't do that 😂.

Copy link
Contributor

Choose a reason for hiding this comment

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

Double-reversal: Conjunctions will work if you change the negations in the jump-identification from using into1 etc. to intoImpl1 etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, that's true. This is subtle enough that I think I'll just leave this as-is, and we can change it if it turns out that we get too many TKinds (which I really doubt since they're already restricted to the ones occurring in a PathNode).

@MathiasVP
Copy link
Contributor Author

DCA looks fine now 🎉.

@MathiasVP MathiasVP merged commit 27c4408 into github:main May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants