This is a RFC, the intent of this is to improve tonto speed and hopefully other
Fortran testcases.
I'll attach a WIP patch.
What it currently does is from frontend-passes.c walks down procedure body and
tries to determine all possible POINTER assignments (currently for POINTER vars
only, no POINTER components), computing points_to list for each suitable
POINTER var. NULL points_to means points to not computed, or could point to
anything.
Otherwise it can contain other symbols, the fact that ALLOCATE has been used on
some pointer, that it is nullified, that it inherits its value from caller for
dummy vars or that a callee might set the var.
Currently the patch doesn't implement interprocedural analysis (we give up
immediately on GFC_PT_CALL). Eventually, for GFC_PT_CALL we should be able to
look up if we have points_to for the corresponding dummy argument and somehow
try to remap the stuff from its points_to to current function.
GFC_PT_DUMMY obviously can map to whatever we pass to that argument,
GFC_PT_NULL is null as well, similarly GFC_PT_ALLOCATE, for other pointers just
recurse and
remap what they point to, for stuff like module vars I'm afraid the FE syms
might not be shared, or for COMMONs etc.
Another thing which still needs solving is distinction between full pointer
assignments and partial ones (ptr => x vs. ptr => y(:, 1) ), as for the latter
ones we should simply give up if we find out symbols might be same, instead of
trying to do some dependency resolution.
For tonto there is another problem, create_ and destroy method subroutines are
defined in a different file, so in order to optimize that we'd probably need to
save the computed points_to info into *.mod file and read it from that again.
--
Summary: Implement simple static points-to analysis in Fortran FE
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
