This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <uday@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.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]