Dataflow: Remove tracked types from Access Paths, track tainted object type, and tweak type pruning. #18179
Conversation
This file contains 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
aschackmull
force-pushed
the
dataflow/accesspath-notypes
branch
from
f7932dc to
5feb737
Compare
aschackmull
force-pushed
the
dataflow/accesspath-notypes
branch
from
5feb737 to
b65a4e4
Compare
hvitved
reviewed
Dec 4, 2024
| @@ -3006,6 +3050,12 @@ module MakeImpl<LocationSig Location, InputSig<Location> Lang> { | |||
| ) | |||
| } | |||
|
|
|||
| private string ppStored() { | |||
There was a problem hiding this comment.
This predicate is duplicated, so perhaps pull it out via
private class TypOption extends TypOption::Option {
string pp() {
exists(string ppt | ppt = this.toString() |
if this.isNone() or ppt = "" then result = "" else result = " : " + ppt
)
}
}| @@ -891,6 +891,8 @@ module MakeImplCommon<LocationSig Location, InputSig<Location> Lang> { | |||
| nodeDataFlowType(this.asNode(), result) | |||
| or | |||
| nodeDataFlowType(this.asParamReturnNode(), result) | |||
| or | |||
| isTopType(result) and this.isImplicitReadNode(_) | |||
There was a problem hiding this comment.
Are we certain that isTopType always has results?
There was a problem hiding this comment.
Reasonably sure, but not completely. There are two options: Either we make it part of the language-specific input, or we make it a consistency check. I think I like the latter to avoid add yet another predicate in the input.
There was a problem hiding this comment.
A consistency check sounds fine to me.
There was a problem hiding this comment.
Found to fail on C# with
DataFlowType should have one top type that's compatible with all other types, but has 3.
That's harmless, but not intentional, so agreed to add this to the input signature instead as a followup.
aschackmull
force-pushed
the
dataflow/accesspath-notypes
branch
from
29d3c51 to
c187a7a
Compare
hvitved
approved these changes
Dec 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR changes how type pruning is done in the data flow library. The primary change is that access paths no longer carry information about tracked types. On its own, this is a precision reduction, so it's combined with a separate precision improvement in that we now track the type of the originally tainted object - this corresponds to the innermost type in an access path, if available, prior to this PR. These two changes mostly balance each other in terms of overall precision, but of course they also affect performance. For Java on MRVA top 1000, this effect was slightly negative with two projects having big degradations in terms of number of computed tuples in certain queries. However, without types in access paths, this now allows other changes, so this PR contains a third tweak that postpones type pruning until stage 5. And this latter tweak regains the lost performance and then some, so the overall effect looks like a net win on almost all of MRVA top 1000.
I also checked impact on C# MRVA top 1000, but there the effects were negligible. And other languages are likely even less affected, since this only deals with type pruning, which isn't used much beyond Java and C#.
Commit-by-commit review is encouraged. The first two commits are simple refactorings. And the subsequent 3 commits implement the 3 changes described above.