On Thu, Jan 24, 2013 at 3:17 PM, Uday P. Khedker <u...@cse.iitb.ac.in> wrote:
>
>
> Richard Biener wrote, On Thursday 24 January 2013 05:28 PM:
>
>
>>> In the program below, we have a global pointer p that has conditional
>>> assignments before its
>>> use on the RHS of a copy statement.
>>>
>>> -----------------------------------------------------------------------------------------
>>> #include<stdio.h>
>>>
>>> int **p;
>>> int main()
>>> {
>>> int *x,*y,a,c,*z;
>>> x = &a;
>>> z = &c;
>>> if(a)
>>> p = &x;
>>> else
>>> p = &y;
>>> int **t = p;
>>> printf("%d,%d",*z,*x);
>>> }
>>>
>>> -----------------------------------------------------------------------------------------
>>> The assignment t=p does not seem to load p inspite of p being a global
>>> pointer. Here's
>>> the relevant code fragment from test.c.017t.ssa:
>>>
>>> ----------------------------------------------------------------------------------------
>>> <bb 3>:
>>> p = &x;
>>> goto <bb 5>;
>>>
>>> <bb 4>:
>>> p = &y;
>>>
>>> <bb 5>:
>>> t_3 = p;
>>
>>
>> here p is loaded directly into t_3, you can consider it optimized
>> (copy propagated)
>> from
>>
>> D.1234_8 = p;
>> t_3 = D.1234_8;
>>
>>> x.1_4 = x;
>>> D.2524_5 = *x.1_4;
>>> D.2525_6 = *z_1;
>>>
>>> ---------------------------------------------------------------------------------------
>>> Note that p is global but it has been loaded neither loaded, nor does it
>>> have a PHI function.
>>
>>
>> As p resides in memory it does not need a PHI - values are merged by
>> storing them to memory.
>
>
> Yes, but because it is in memory, should it not be loaded? I thought every
> memory
> access is preceded by a load. At least that is how I interpreted your
> original statement.
My original statement was that if you have a memory access through a
pointer, *p, in C terms then p will be loaded into an SSA name first (if p is
not already an SSA name). In your example p is not dereferenced.
Thus, more precise "every indirect memory access to *p is preceeded by a load
of the pointer p to an SSA name".
>
>>
>>> There is no way we can put the pointees of p in SSA_NAME_PTR_INFO of p in
>>> a
>>> flow sensitive
>>> manner.
>>>
>>> So if a later optimization pass were to find out aliases of p or pointees
>>> of
>>> p for the statement
>>> t_3 = p, I don't know how will we supply the information that was
>>> discovered
>>> by our analysis.
>>
>>
>> Your analysis should have come across that statement
>>
>> t_3 = p;
>>
>> and record that t_3 points to what p points to at this point of the
>> program,
>> thus compute a solution for all SSA name pointers.
>
>
> Yes that is easy to do. But my concern is what if there is a pass that
> requires/uses pointer
> information of p in the statement t_3 = p.
Then it would have no way of getting at it. Likewise if there is a global x
struct { int i; int *p; double d; } x;
and a pass would want to get at pointer information of x.p.
But why would any pass want pointer information of p or x.p if there
is no use of p or x.p as pointer in the program? And if there is, then
the pointer will be loaded to an SSA name and used as SSA name.
Thus the pass will never want to query pointer information on memory
but only on SSA names (as those are the only ones that get dereferenced
and thus used).
At least it should work 99% of the cases in this way - and I can't currently
think of an example for the remaining 1% - though I'm sure there may be
some obscure case.
>>
>> This is what the present points-to algorithm does, and at the end it
>> simply
>> discards anything but the solutions computed for SSA name pointers
>> which are stored in SSA_NAME_PTR_INFO.
>
>
> Oh, does it mean that the SSA_NAME_PTR_INFO would not be present for p
> but would be present only for t_3 (because p is not an SSA name and t_3 is)?
Yes.
> If this is true, can we assume the invariant that any pass would seek
> pointer
> info only for SSA names and not for any non-SSA name?
Yes, that is my belief.
> If that is the case, then I think there is a simple way in which we can make
> the
> result of our analysis available to all other passes without they having to
> consult our data structure.
Yes.
Richard.
>
> Uday.
>
