-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Shared: Prepare model generation for C++ adoption #19273
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
Shared: Prepare model generation for C++ adoption #19273
Conversation
…out of the class signature.
Yes, we should probably use the mad-queries suites in DCA for Java and C# to check performance (and stability of constructed models). These also print some model diff output as well as measure the performance. For technical reasons the DCA experiment needs the query suite both as the query suite being executed but also as "uninterpreted" queries. If you want to add a similar DCA suite for C++ we might need to make some changes to DCA to support the model generator related summaries for C++? I will start some experiments for C# (for .NET Runtime) and Java (SDK). 😄 |
Uh, yeah that sounds good. We can maybe discuss that once we've got this merged and #19274 (at which point I can actually open a PR that implements |
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.
Fantastic!
@@ -687,7 +694,7 @@ module MakeModelGenerator< | |||
private DataFlow::ParameterNode parameter; | |||
|
|||
ContentDataFlowSummaryTargetApi() { | |||
count(string input, string output | | |||
strictcount(string input, string output | |
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.
Uh, nice catch!
@MathiasVP : I ran the modelgenerator on |
Thanks for checking 🙇 I'll go ahead and hit the Big Green Button then 🚀 |
This PR slightly generalizes the model generation input signature to allow for a smooth C++ adoption:
asParameter
out of theNodeExtended
signature. This is necessary because the return type of C++'sNode.asParameter
is different from the actual parameter nodes we use inside dataflow.getEnclosingCallable
out of theNodeExtended
for similar reasons. I also movedgetAsExprEnclosingCallable
for symmetry.ReturnValue
string forValueReturnKind
s. This necessary because C++ hasReturnValue
,ReturnValue[*]
,ReturnValue[**]
, etc, for returningp
,*p
,**p
from a function.Additionally, I fixed a potential cartesian product in a1dc874 that I was hitting when testing MaD on a large C++ repository internally at Microsoft.
Commit-by-commit review recommended.
@michaelnebel does this need additional testing other than CI? And if so, how do I go about doing that?