Re: effect of globals on SSA Form

cliffc@rice.edu (Cliff Click)
Fri, 17 Dec 1993 17:26:55 GMT

          From comp.compilers

Related articles
effect of globals on SSA Form sskumar@vela.acs.oakland.edu (1993-12-13)
Re: effect of globals on SSA Form cliffc@rice.edu (1993-12-17)
| List of all articles for this month |

Newsgroups: comp.compilers
From: cliffc@rice.edu (Cliff Click)
Keywords: optimize
Organization: Center for Research on Parallel Computations
References: 93-12-052
Date: Fri, 17 Dec 1993 17:26:55 GMT

sskumar@vela.acs.oakland.edu (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
> information?


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.


Cliff
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.