------- Comment #5 from mikael at gcc dot gnu dot org 2010-09-10 00:32 -------
I agree that the front-end is missing a statement walker to infer information
out of the code.
However, if find the static points-to approach a bit too "static".
For example, consider a case like this:
ptr => a
! Do stuff
ptr => b
ptr = a + 1
There is no way the static points-to can tell that in the last statement `ptr'
and `a' can't alias.
However, as we are walking the code sequentially, and because the code is
purely sequential, we can guess easily that `ptr' and `a' can't alias.
Thus, what I imagine is a function that tells (by looking directly at the code)
whether a specific alias can happen, given as argument the pointer, the target
and the statement where we want to know the alias information. The later
argument can be ignored in an initial implementation, so that the function
would have essentially the same outline as Jakub's compute_spt_code. But it can
be improved later to handle (as time permits) sequential pointer assignments,
loops, goto, etc.
Now, for cross-file checking, there is probably no way but a static points-to
list. It is however easy to build such a list once there is a working pointer
analysis function. I haven't thought about the problem much in depth though.
To sum up all this lengthy answer (and add more length to it), I find it a bit
sad to compute alias information out of partial information (static points-to)
when we have the full information (the actual code) available.
We should build static points-to out of alias information rather than build
alias information out of static points-to. ;-)