This is the mail archive of the
mailing list for the GCC project.
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
On Thu, Oct 11, 2012 at 5:04 AM, Uday P. Khedker <email@example.com> wrote:
> Hi David,
>> This is great progress.
>> 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
> 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
> assumes flow insensitive information. Supporting flow sensitivity implies
> being able
> to provide different information for the same pointer at different program
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
> 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
> (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
> 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
> Thanks and regards,