Query regarding pointer analysis

[mukta]

We are trying to find how pointer analysis information is being used
by other optimizations in gcc. We disovered that pointer information
is stored as a bitmap which is accessed via a macro named
"SSA_NAME_PTR_INFO". However, when we tried to find where this macro
is being used, we came up with following observations:

For the example given below:

int main()
{
int *a,*b;

int p,q,r;

a = &r;

*a = p + q;

b = &p;

*b = p + q;

printf("%d,%d",*a,*b);
}

There is scope for copy propagation, and the program does get
optimized stating that *a should be equal to *b. Pass
"COPY_PROPAGATION" has a call to SSA_NAME_PTR_INFO wherein it
duplicates the points-to information in case of copy propagation.
However, for the example given above, this macro is not being called.
Here, we realized that the pointer dereferences are already converted
to scalar variables in the first execution of the pass "CONDITIONAL
CONSTANT PROPAGATION". However, this pass also does not seem to call
the macro SSA_NAME_PTR_INFO.

Thus, we are not sure how exactly this conversion takes place.

In general, we need answers for the following questions :
1. How are the pointer dereferences converted to scalar variables and
whether points-to information is being used for this conversion or
not?
2. Which passes use pointer information?
3. How does the pointer information exactly help these passes in
optimizations?
4. How do the passes that execute before the pta pass deal with
pointers? For instance following passes have one execution before
pass_ipa_pta and another execution after it.
pass_ccp
pass_build_ealias
pass_sra_early
pass_fre
pass_copy_prop
pass_merge_phi
pass_cd_dce

Can anyone help us with this issue?

[Andrew Haley]

mukta <mukta.j...@gmail.com> wrote:

> We are trying to find how pointer analysis information is being used
> by other optimizations in gcc. We disovered that pointer information
> is stored as a bitmap which is accessed via a macro named
> "SSA_NAME_PTR_INFO". However, when we tried to find where this macro
> is being used, we came up with following observations:

> Can anyone help us with this issue?

You should send this to the gcc mailing list.

Andrew.