On Thu, Oct 11, 2012 at 5:04 AM, Uday P. Khedker <u...@cse.iitb.ac.in> wrote: > Hi David, > >> This is great progress. > > > Thanks. > > >> >> If I understand the experiments, your implementtion has very small >> cost to perform the analysis, at least for the SPEC benchmarks you are >> testing. Have you connected the analysis to any optimizations? Is >> there any improvement in performance on SPEC CPU or other >> applications? > > > Unfortunately we could not do this as it requires changing the way the > pointer information > is made available to other passes. Right now, it is encoded in the TREE > nodes of > variables which make is same at all program points. In other words, GCC, by > definition > assumes flow insensitive information. Supporting flow sensitivity implies > being able > to provide different information for the same pointer at different program > points.
That's actually not true. In fact existing GCC pointer analysis is flow-sensitive for all SSA pointers. Points-to information is associated with each (and only with!) SSA pointer variable via SSA_NAME_PTR_INFO. > We are investigating how this can be done and this is one of the most > important future > works on which we seek collaboration. Unless we are able to do this, we will > not be able > to take advantage of the analysis. I suggest to look at the above and the disambiguators that use points-to information in tree-ssa-alias.c (and their helpers in tree-ssa-struct-alias.c). >> >> You ask for collaboration, but it's not clear what state the >> infrastructure is in, how complete it is, and what more needs to be >> done. > > > The infrastructure is in a reasonably complete state except that > (a) It is not directly useful to other analyses and optimizations for the > reasons described above. > (b) It uses rather naive and inefficient data structures in which sets are > stored as linked lists and set operations are implemented using linear > searches. > (c) Some corner cases related identifying pointers need to be fixed. > (d) It handles heap locations rather conservatively. > > We seek collaborations on (a) and (b). We have designed APIs to hide the > data structures > and now these are good student projects. Some details can be found at > http://www.cse.iitb.ac.in/grc/gcc-workshop-12/index.php?page=projects#Projects_with_Concrete_and_Detailed. > > We are carrying out research on (d) and have some ideas on what needs to be > done but it will > be some time before the infrastructure is enhanced to include it. We are > committed to doing it. I'd be interested to know how you analysis (is it interprocedural at all?) scales on programs the existing IPA PTA blows up (in both compile-time and memory-usage, usually first memory-usage ;)). Did you investigate on how to handle whole-program PTA at link-time with our distributed WHOPR mode (thus at no point a single compiler process sees all function bodies of the program but WPA phase sees the whole program callgraph). Thanks, Richard. > Thanks and regards, > > Uday. > >
