Re: [Tree-SSA] Question from observation, bogus SSA form?
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.
Re: [Tree-SSA] Question from observation, bogus SSA form?
On 16/03/2023 17:30, Martin Jambor wrote: Hello Pierrick, On Thu, Mar 16 2023, Pierrick Philippe wrote: Hi everyone, I was working around with the analyzer, but I usually dump the SSA-tree to get a view of the analyzed code. This is how I noticed something wrong, at least in the sense of the definition of SSA form. please note that only some DECLs are put into a SSA form in GCC, these are sometimes referred to as "gimple registers" and you can query the predicate is_gimple_reg to figure out whether a DECL is one (putting aside "virtual operands" which are a special construct of alias analysis, are in an SSA form but the predicate returns false for them for some reason). 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. I mean, aren't they any passes relying on the pure SSA form properties to analyze code? For example to DSE or DCE. [stripping] The thing is, there is two distinct assignment to the same LHS tree at two different gimple statement, which is by definition not supposed to happened in SSA form. I think it is now clear that x is not in SSA form because (at this stage of the compilation) it is still considered to need to live in memory. I think that I get your point. It would be a heavy design change to be able to write it in pure SSA form. Is there any particular reason this happen? Is that because the address of x is taken and stored? I have to precise, I did not dig into the SSA form transformation and am a newbie to gcc source code. So maybe my question is a bit naive or a known issue. No worries, we know these important details are not straightforward when you see them for the first time. Good luck with your gcc hacking! Thanks! :) Pierrick
Re: [Tree-SSA] Question from observation, bogus SSA form?
Hello Pierrick,
On Thu, Mar 16 2023, Pierrick Philippe wrote:
> Hi everyone,
>
> I was working around with the analyzer, but I usually dump the SSA-tree
> to get a view of the analyzed code.
> This is how I noticed something wrong, at least in the sense of the
> definition of SSA form.
please note that only some DECLs are put into a SSA form in GCC, these
are sometimes referred to as "gimple registers" and you can query the
predicate is_gimple_reg to figure out whether a DECL is one (putting
aside "virtual operands" which are a special construct of alias
analysis, are in an SSA form but the predicate returns false for them
for some reason).
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.
>
> I'm using a version of gcc build from a /trunk/ branch (/20230309/).
>
> Here is an example code:
>
> '''
> int main(void) {
> int x = 42;
> int * y = &x;
Here you take address of x which therefore has to live in memory at
least as long as y is not optimized away.
> x = 6;
> return x;
> }
> '''
>
> And here is the output from -fdump-tree-ssa-vops:
>
> '''
> ;; Function main (main, funcdef_no=0, decl_uid=2739, cgraph_uid=1,
> symbol_order=0)
>
> int main ()
> {
> int * y;
> int x;
> int D.2744;
> int _5;
>
> :
> # .MEM_2 = VDEF <.MEM_1(D)>
> x = 42; // First assignment
> to var_decl x
> y_3 = &x;
> # .MEM_4 = VDEF <.MEM_2>
> x = 6; // Second
> assignment to var_decl x
> # VUSE <.MEM_4>
> _5 = x;
> # .MEM_6 = VDEF <.MEM_4>
> x ={v} {CLOBBER(eol)};
>
> :
> :
> # VUSE <.MEM_6>
> return _5;
>
> }
> '''
>
> The thing is, there is two distinct assignment to the same LHS tree at
> two different gimple statement, which is by definition not supposed to
> happened in SSA form.
I think it is now clear that x is not in SSA form because (at this stage
of the compilation) it is still considered to need to live in memory.
> Is there any particular reason this happen? Is that because the address
> of x is taken and stored?
>
> I have to precise, I did not dig into the SSA form transformation and am
> a newbie to gcc source code.
> So maybe my question is a bit naive or a known issue.
No worries, we know these important details are not straightforward when
you see them for the first time.
Good luck with your gcc hacking!
Martin
