-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add model call tests #53
Conversation
...bm.wala.cast.python.ml.test/source/com/ibm/wala/cast/python/ml/test/TestTensorflowModel.java
Outdated
Show resolved
Hide resolved
...bm.wala.cast.python.ml.test/source/com/ibm/wala/cast/python/ml/test/TestTensorflowModel.java
Show resolved
Hide resolved
...bm.wala.cast.python.ml.test/source/com/ibm/wala/cast/python/ml/test/TestTensorflowModel.java
Outdated
Show resolved
Hide resolved
This is looking good. Thanks. For each of the model calls, what does the IR look like? |
I think there are two problems here:
|
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.
Thanks!
Can you also throw this up to http://github.com/wala/ML? |
|
For For
and for call body, the node is
|
We need the IR for this node.
Let's focus on the
We don't need the body, just the client code. Actually, the node name alone would be helpful:
|
1 similar comment
We need the IR for this node.
Let's focus on the
We don't need the body, just the client code. Actually, the node name alone would be helpful:
|
For For For
|
We need the IR of the calling functions (callers). |
For
For
|
Comparison of the IR of all the nodes for Please see this gist linked here. |
Thanks. Here is test 4 that works:
|
Here is test 1 that doesn't work:
|
In case 4, the function being invoked is in |
In test 4, we can see that
Thus, in test 1, the "function" being invoked is |
Correct, we are falling into that |
It enters that method for instructions that in
Also when it has
Yes, in both cases it has the same behavior in |
So what is going on in that else clause? How are the targets being resolved? |
Are they being added through the side effects? |
In https://github.com/wala/WALA/blob/d7b408901e928aaf63c0d9f9b24a46403eb55d60/core/src/main/java/com/ibm/wala/ipa/callgraph/propagation/SSAPropagationCallGraphBuilder.java#L1181, we have that test 1 gets 265 which is the instruction of the ctor and for test 4 (working test) it get the instruction 269 which is
|
Yeah, but what's going on with the side effects? Is that how the edges are eventually created? See this log: You are hitting that for both cases, right? If so, what is going on here: Is that adding side effects that eventually get turned into edges in the call graph? |
The working case should create an edge, whole the non-working case should not. |
Hey @msridhar, thanks again for this idea. The problem we are having here is that, in the latter case above (...if an object value I understand that the CG construction creates nodes on-the-fly, so maybe it's a chicken and egg problem. Thanks again for your help! |
Sorry for the noise, @msridhar. I think what we are missing is that we need to add the invocation statement, and later in the worklist,-based algorithm, that will be picked up and the node will then be created. |
The CG of the non-working case is the following:
|
Thanks, @tatianacv. Can you find in the call graph construction algorithm where it is processing |
Yes, we start processing that node in
It goes to
What I found and the reason why call is referencing to ML/com.ibm.wala.cast.python/source/com/ibm/wala/cast/python/client/PythonAnalysisEngine.java Lines 288 to 291 in 386512a
Therefore, when we are in v265 (the result of the ctor), the receiver Core[script tf2_test_model_call.py/SequentialModel] which is used to get the target (https://github.com/ponder-lab/ML/blob/386512a3d439213f1c64de48473db1baaa006735/com.ibm.wala.cast.python/source/com/ibm/wala/cast/python/ipa/callgraph/PythonConstructorTargetSelector.java) has in the methodTypes : [< PythonLoader, Lscript tf2_test_model_call.py/SequentialModel/__init__, __init__()LRoot; >, < PythonLoader, Lscript tf2_test_model_call.py/SequentialModel/__call__, __call__()LRoot; >] . This gets processed in this PythonConstructorTargetSelector.getCalleeTarget(...) and creates statements for __call__ , which we see in the instructions and references the v265 (the result of the ctor), but does not add the __call__ . Since __call__ is in the methodTypes , we process the __call__ in this code snippet:Lines 74 to 139 in 386512a
The results of the added statements for
Just for reference all statements are |
Link?
Link?
I don't think this was ever under question. |
The variable So, to answer this question:
I am seeing this in the pointer analysis:
That means that |
I wonder if the |
So, when |
BTW, the receiver here is an instance of |
The |
The corresponding |
In the non-working case, the |
I should have mentioned that in the working case, |
In the non-working case, that method returns
It's in: https://github.com/wala/WALA/blob/5aa300b2d0f0c672d027d9d896792985e1a69424/core/src/main/java/com/ibm/wala/ipa/summaries/BypassMethodTargetSelector.java#L139. The variable |
Thanks for finding the |
In the working case, the instance key is:
In the non-working case, it is:
|
The problem I'm seeing now is that the pointer analysis is unavailable in |
Looks like |
If I run |
Yeah, but it shouldn't even matter whether |
Actually, I think that the Lines 163 to 165 in 2fb00a1
|
Move the conversation over to wala#24. |
Adding tests for testing calling a method. We add four test that include
call
and__call__
(2 tests)call
and__call__
(2 tests)Related to wala#24