|effect of globals on SSA Form email@example.com (1993-12-13)|
|Re: effect of globals on SSA Form firstname.lastname@example.org (1993-12-17)|
|From:||email@example.com (Cliff Click)|
|Organization:||Center for Research on Parallel Computations|
|Date:||Fri, 17 Dec 1993 17:26:55 GMT|
firstname.lastname@example.org (Srikanth Kumar) writes:
> Hi, I would like to know how side effect information is represented
> in Static Single Assignment Form.
Why, any way you like, of course. ;-)
> g_1 = ... /* g_1 is a global (a version of global 'g') */
> call p() /* p modifies global g */
> = use of g here /* which version of g is used? */
> How is side effect information represented in SSA with/without MOD
My implementation carries around a special "memory" value, which is
created by stores and used by loads. Language semantics (i.e. global
variables, compiler temporaries, etc) allows me to have several smaller
"memories" instead of one big one. This is essentially *very*
conservative alias analysis. Beyond that, I plan on using the traditional
techniques (read that as: "it's not implemented so I haven't thought about
the messy details, but it looks doable").
For your example, "call p()" defines a new value for global g, call it
"g_2". The later use is of "g_2". "call p()" probably defines lots of
new values; at least one new value for every unalised-thing modified. For
aliased things, "call p()" defines one new value for every aliased set
potentially modified. The one new value essentially kills all the aliased
things in that set.
With some care the issues of SSA representation and pointer/alias analysis
are orthogonal. You can do as much or as little pointer/alias analysis as
you can stomach with or without SSA.
email@example.com -- Massively Scalar Compiler Group, Rice University
Return to the
Search the comp.compilers archives again.