Hello,
On Fri, 17 Mar 2023, Pierrick Philippe wrote:
> > This means that global variables, volatile variables, aggregates,
> > variables which are not considered aggregates but are nevertheless
> > partially modified (think insertion into a vector) or variables which
> > need to live in memory (most probably because their address was taken)
> > are not put into an SSA form. It may not be easily possible.
>
> Alright, I understand, but I honestly find it confusing.
You can write something only into SSA form if you see _all_ assignments to
the entity in question. That's not necessarily the case for stuff sitting
in memory. Code you may not readily see (or might not be able to
statically know the behaviour of) might be able to get ahold of it and
hence change it behind your back or in unknown ways. Not in your simple
example (and if you look at it during some later passes in the compiler
you will see that 'x' will indeed be written into SSA form), but in some
that are only a little more complex:
int foo (int i) {
int x, *y=&x;
x = i; // #1
bar(y); // #2
return x;
}
or
int foo (int i) {
int x, z, *y = i ? &x : &z;
x = z = 1; // #1
*y = 42; // #2
return x;
}
here point #1 is very obviously a definition of x (and z) in both
examples. And point #2? Is it a definition or not? And if it is, then
what entity is assigned to? Think about that for a while and what that
means for SSA form.
> I mean, aren't they any passes relying on the pure SSA form properties
> to analyze code? For example to DSE or DCE.
Of course. They all have to deal with memory in a special way (many by
not doing things on memory). Because of the above problems they would
need to special-case memory no matter what. (E.g. in GCC memory is dealt
with via the virtual operands, the '.MEM_x = VDEF<.MEM_y>' and VUSE
constructs you saw in the dumps, to make dealing with memory in an
SSA-based compiler at least somewhat natural).
Ciao,
Michael.
