From: Michael Matz <matz@suse.de>
To: Pierrick Philippe <pierrick.philippe@irisa.fr>
Cc: Martin Jambor <mjambor@suse.cz>, gcc@gcc.gnu.org
Subject: Re: [Tree-SSA] Question from observation, bogus SSA form?
Date: Fri, 17 Mar 2023 14:34:30 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2303171419250.16810@wotan.suse.de> (raw)
In-Reply-To: <b481e40c-5ca6-504b-e3d6-87add8513a88@irisa.fr>
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.
prev parent reply other threads:[~2023-03-17 14:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 15:26 Pierrick Philippe
2023-03-16 16:30 ` Martin Jambor
2023-03-17 13:55 ` Pierrick Philippe
2023-03-17 14:34 ` Michael Matz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.2303171419250.16810@wotan.suse.de \
--to=matz@suse.de \
--cc=gcc@gcc.gnu.org \
--cc=mjambor@suse.cz \
--cc=pierrick.philippe@irisa.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).