Problem in understanding points-to analysis
Hello everyone,
I am trying to understand the points-to analysis ("pta") ipa pass, but
I am not able to match the information generated by the pass and that
in structure "SSA_NAME_PTR_INFO".
For the code segment,
--
int var1, var2, var3, var4, *ptr1, *ptr2, **ptr3;
if (var1==10) {
ptr1 = &var1;
ptr2 = &var2;
}
else {
ptr1 = &var3;
ptr2 = &var4;
}
if (var2==3) {
ptr3 = &ptr1;
}
else {
ptr3 = &ptr2;
}
printf("\n %d %d \n",*ptr1, **ptr3);
--
The points-to information in dump_file of "pta" pass:
ptr1.2_6 = { var1 var3 }
ptr1 = { var1 var3 } same as ptr1.2_6
But accessing the structure "SSA_NAME_PTR_INFO" (using API
dump_points_to_info_for(..) ) in a pass AFTER "pta", shows
ptr1.2_6, points-to vars: { var1 var3 }
ptr1, points-to anything
Why here 'ptr1' is not pointing to '{ var1 var3 }' as found by "pta"?
Can someone please help me understand this behaviour?
--
Thanks,
Nikhil Patil.
Computation and usage of SSA_NAME_PTR_INFO
Hello, 1. Which passes of gcc make use of points-to information in SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing optimizations? 2. Also, who computes this points-to information and populates pt_solution? Is it ONLY ipa-pta pass? When I accessed pt_solution through a plugin which REPLACES ipa-pta pass, I found that the information (in pt_solution) with and without ipa-pta pass differs only in terms of flags in pt_solution. Here with the examples I could construct, I found that the bitmap 'vars' in pt_solution is same for both the cases. Is it always true? Can someone please help in clarifying these doubts. Thanks in advance. -- Regards, Nikhil Patil.
Re: Computation and usage of SSA_NAME_PTR_INFO
On Tue, Apr 30, 2013 at 1:32 PM, Richard Biener wrote: > On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil > wrote: >> Hello, >> >> 1. Which passes of gcc make use of points-to information in >> SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing >> optimizations? > > All passes that query the alias oracle (tree-ssa-alias.h) which is almost > all passes doing optimization of memory accesses. Thanks a lot for giving direction. I will try finding the passes. > >> >> 2. Also, who computes this points-to information and populates >> pt_solution? Is it ONLY ipa-pta pass? > > It is points-to analysis, both the IPA variant and the local variant > (ealias and alias > passes). >From what I could understand, gimple passes "pass_build_ealias" (ealias) and "pass_build_alias" (alias) flags "TODO_rebuild_alias" at end and then function "execute_function_todo" from passes.c calls "compute_may_aliases ()" which eventually computes points-to information. Then the IPA PTA pass finds a more precise points-to information. Please correct if I am wrong. > >> When I accessed pt_solution through a plugin which REPLACES ipa-pta >> pass, I found that the information (in pt_solution) with and without >> ipa-pta pass differs only in terms of flags in pt_solution. Here with >> the examples I could construct, I found that the bitmap 'vars' in >> pt_solution is same for both the cases. Is it always true? > > In theory IPA PTA should be able to compute a more precise solution, > thus have different (less) bits set in 'vars'. There are several testcases > that show this, look for ipa-pta* testcases in gcc/testsuite/ > > Richard. > >> Can someone please help in clarifying these doubts. >> >> Thanks in advance. >> >> -- >> Regards, >> Nikhil Patil. -- Regards, Nikhil Patil.
Re: Computation and usage of SSA_NAME_PTR_INFO
On Thu, May 2, 2013 at 1:16 PM, Richard Biener wrote: > On Wed, May 1, 2013 at 5:11 PM, Nikhil Patil > wrote: >> On Tue, Apr 30, 2013 at 1:32 PM, Richard Biener >> wrote: >>> On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil >>> wrote: >>>> Hello, >>>> >>>> 1. Which passes of gcc make use of points-to information in >>>> SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing >>>> optimizations? >>> >>> All passes that query the alias oracle (tree-ssa-alias.h) which is almost >>> all passes doing optimization of memory accesses. >> >> Thanks a lot for giving direction. I will try finding the passes. >> >>> >>>> >>>> 2. Also, who computes this points-to information and populates >>>> pt_solution? Is it ONLY ipa-pta pass? >>> >>> It is points-to analysis, both the IPA variant and the local variant >>> (ealias and alias >>> passes). >> >> From what I could understand, gimple passes "pass_build_ealias" >> (ealias) and "pass_build_alias" (alias) flags "TODO_rebuild_alias" at >> end and then function "execute_function_todo" from passes.c calls >> "compute_may_aliases ()" which eventually computes points-to >> information. > > Correct. > >> Then the IPA PTA pass finds a more precise points-to information. >> Please correct if I am wrong. > > Well. The IPA PTA pass is supposed to compute a points-to solution > for the whole translation unit, thus it should be more precise. Due to > limitations and bugs in IPA PTA the result does not necessarily have to > be more precise. > > I do not consider the current IPA PTA code production ready (it does > not scale very well and it doesn't result in any performance improvements > for SPEC 2k6). > > It's a long-time item on my personal TODO list to at least address the > fundamental problems with the current implementation (read: bugs). > But my TODO list is quite crowded ... Thanks a lot. The discussion gave me a more insight into the topic and solved my doubts. > > Richard. > >>> >>>> When I accessed pt_solution through a plugin which REPLACES ipa-pta >>>> pass, I found that the information (in pt_solution) with and without >>>> ipa-pta pass differs only in terms of flags in pt_solution. Here with >>>> the examples I could construct, I found that the bitmap 'vars' in >>>> pt_solution is same for both the cases. Is it always true? >>> >>> In theory IPA PTA should be able to compute a more precise solution, >>> thus have different (less) bits set in 'vars'. There are several testcases >>> that show this, look for ipa-pta* testcases in gcc/testsuite/ >>> >>> Richard. >>> >>>> Can someone please help in clarifying these doubts. >>>> >>>> Thanks in advance. >>>> >>>> -- >>>> Regards, >>>> Nikhil Patil. >> >> -- >> Regards, >> Nikhil Patil. -- Regards, Nikhil Patil.
