SSA construction and aliased variables

Ladies/Gentlemen,


I have a question of how SSA form should treat aliased variables and
globals. I was unable to find any mention of the problem in all works
on SSA that I've read.


Scenarion:
If we have global p in the following code


if (a)
        {
        p = 1;
        }
else
        {
        p = 2;
        }
...


naive translation will do the following:


if (a)
        {
        p1 = 1;
        }
else
        {
        p2 = 2;
        }


p3 = psi(p1, p2);


and it will be fine. When we translate back from SSA,
we move assignments to p3:


if (a)
        {
        p1 = 1;
        p3 = p1;
        }
else
        {
        p2 = 2;
        p3 = p1;
        }


and feed it to register allocator.


However, if the code is


if (a)
        {
        p = 1;
        }
else
        {
        p = 2;


        function_call();
        }


the result from translation back from SSA in the form


if (a)
        {
        p1 = 1;
        p3 = p1;
        }
else
        {
        p2 = 2;
        p3 = p1;
        function_call ();
        }


is incorrect because function_call may change p.


Trivial solution that comes to mind right away is to treat assignments
of globals and aliased variables in low-level intermediate code as a
deref, i. e. not consider global or aliased tags as SSA-able resources
at all


load reg, global


then has out reg (variable), and in deref function of global (not SSA
variable). And just let PRE or value numbering deal with it as an
expression, and account for side effects of aliasing and function
calls.


Is there more intelligent way of dealing with this?


Any insights/references deeply appreciated.


Regards --


Sergey Solyanik
Software Developer
Bentley Systems, Inc


Sergey.Solyanik@bentley.com
--

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