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.
Re: Question About GPU-Powered Parallel Compilation in GCC
Hi Richard, Thank you so much for the reply! You're absolutely right about using CPU threads. I’m just really curious about whether GPU acceleration could somehow be explored for compilation, even if it’s not traditionally well-suited. I know it might not be practical, but I wanted to understand *why* it’s considered inefficient and learn through experimentation. I’m still a student and just starting to explore compilers more seriously, so any resources you could recommend to help me learn — especially from the basics — would be incredibly helpful. Thanks again for taking the time to respond! On Mon, 12 May 2025 at 18:51, Richard Biener wrote: > On Mon, May 12, 2025 at 2:55 PM Nikhil Patil via Gcc > wrote: > > > > Hi GCC Team, > > > > I'm fairly new to the world of compilers and trying to understand how > they > > work in more depth. Recently, I started exploring the idea of > *parallelizing > > the internal steps of compilation* — such as parsing, code generation, > and > > optimization — instead of the usual serial approach, and potentially > > leveraging *GPU acceleration* (like CUDA) for this. > > > > I was wondering if this concept has been explored in GCC, or if there are > > any existing resources, discussions, or directions I could look into? > > > > Apologies if this isn’t the right channel — I’m still getting familiar > with > > the community and couldn’t find another communication method. Please let > me > > know if there’s a better place to ask such questions. > > There were two Google Summer of Code projects exploring parallel > compilation using CPU threads. I don't think using a GPU is a good tool > for any of the sub-problems a compiler solves. On the high-level GCC > allows more efficient parallel compilation of multiple source file projects > when using LTO. > > Richard. > > > Best regards, > > *Nikhil Patil* >
Question About GPU-Powered Parallel Compilation in GCC
Hi GCC Team, I'm fairly new to the world of compilers and trying to understand how they work in more depth. Recently, I started exploring the idea of *parallelizing the internal steps of compilation* — such as parsing, code generation, and optimization — instead of the usual serial approach, and potentially leveraging *GPU acceleration* (like CUDA) for this. I was wondering if this concept has been explored in GCC, or if there are any existing resources, discussions, or directions I could look into? Apologies if this isn’t the right channel — I’m still getting familiar with the community and couldn’t find another communication method. Please let me know if there’s a better place to ask such questions. Best regards, *Nikhil Patil*
