Access to symbol table??

[Daniel Berlin]

On 5/31/07, Seema S. Ravandale <ravandale@cse.iitb.ac.in> wrote:
> Hello sir,
>
> Thank you for help. you have already cleared my confusion.
>
> But I am working on inter-procedural data flow analysis. And i am trying
> to implement IPDFA on gimple-CFG IR.

If i were you, I would do it on the gimple-SSA IR, since gimple-CFG
isn't very useful to any optimization apsses.

> So at IR level all usages of global variable are replaced by some local
> variables of kind global.0, global.1 etc...
>
> But I am trying to visualize all of them as usages of global variable.
> In code sample below,let gl is global var.
>
> 1: c = gl+b;
> 2: array[0] = gl;
> 3: gl = 10;
>
> at line number 1,2 gl is used and at line number 3 it is defined.
>
> But in IR we will have...
>
> 1: gl.0 = gl;
> 2: c = gl.0 + b;
> 3: gl.1 = gl;
> 4: array[0] = gl.1
> 5: gl = 10;
>
> so here local variables gl.0 gl.1 are aliased to gl

No, they are copies.  Aliased implies that a store to gl.0 will touch
g.  This is not true.


>
> So i have decided to have some common index to all local version of global
> variables same as index assigned (by me) to corr. global variable. So that
> any occurance of such local variable is interpreted as corr. global
> variable itself.

Why would you want to do this?
What problem do you believe it solves?
That is very wrong in almost any dataflow problem I can think of,
interprocedural or not.

> So i was trying to find whether there is any way GCC stores this
> information or not? And just point of curiosity, how GCC stores scope
> information at IR level...

We simply output debug info and throw away the scope information, as
it is not useful for more than that (when it comes to thinks like
deciding whether two things can go to the same stack location because
they were in different scopes, the scoping info doesn't actually tell
you anything you couldn't discover anyway through dataflow analysis).
--Dan