This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Access to symbol table??
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: ravandale at cse dot iitb dot ac dot in
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 31 May 2007 21:36:20 -0400
- Subject: Re: Access to symbol table??
- References: <53300.10.11.52.67.1180635692.squirrel@www.cse.iitb.ac.in>
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