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.
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.
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.
Thanks and regards,
Uday.
