public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: RFA: New pass to delete unexecutable paths in the CFG
Date: Tue, 08 Nov 2011 20:59:00 -0000	[thread overview]
Message-ID: <4EB99006.4060501@redhat.com> (raw)
In-Reply-To: <4EB98DE2.1050009@gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/08/11 13:15, Paolo Bonzini wrote:
> On 11/08/2011 08:29 PM, Jeff Law wrote:
>>> Just to understand, what does this do with your optimization?
>>> 
>>> void f(void *p) { if (p) { puts("sell_soul_to_devil");
>>> puts("post_reload_rewrite"); }
>>> 
>>> *p = 2; }
>>> 
>>> ... f(NULL);
>>> 
>>> Does the program sell its soul to the devil before crashing?
>> 
>> If "f" is not inlined into its caller, then there's nothing for
>> the new pass to do.  There's no explicit NULL dereference and
>> there's no assignments to "p", so there's no PHI at the merge
>> point for P.
> 
> But is that just a limitation of the representation?  With
> assertions as in VRP you'd have
> 
> if (p_1) goto BB1 else goto BB2 BB1: ... goto BB3; BB2: p_2 =
> assert(p_1, p_1 == 0); goto BB3;
> 
> p_3 = phi (p_1<BB1>, p_2<BB2>); *p_3 = 2;
> 
> What would happen then?
We don't have access to those assertions as they're removed well prior
to this pass running.  However, if we did, or if we had redundant PHIs
in the stream which were propagated we'd be presented with something like

BB0  if (p_1) goto BB1 else goto BB2

BB1: ... goto BB3
BB2:
BB3: p_2 = phi (p_1 (BB1), 0(BB2))
     *p_2 = 2;


We'd recognize that the edge bb2->bb3 is unexecutable as doing so
leads to a NULL pointer dereference.  Since the edge bb2->bb3 is not a
critical edge, we know that bb2 as a whole is unexecutable.  bb2 is
control dependent on the edge bb0->bb2.

We would remove the edge bb0->bb2 and the control statement if (p_1)
....  That makes BB2 unreachable resulting in

BB0 goto BB1
BB1 ...
BB3 p_2 = phi (p_1)
    *p_2 = 2;

Which would then be optimized into

BB0: ...
     *p_1 = 2;

Which is exactly what I would expect the code to do with the knowledge
that passing 0 to f results in undefined behaviour.


jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOuZAGAAoJEBRtltQi2kC7gkwIAJLBfsgICHOWKVBFTAv1U1Xx
8+gR3o70JJmoZY7wOv51ReUOU3Nxzj36f/HzY0SHgNBDu4gxo94HzFkUp1x5u1uw
NUwv802p3JKpIroi8Tonu42mEhIzWGTOIUCLdrxqc3fdPtEMQrC5ExjeKdt//x61
+/JVzz4pNO2ZeYLfATa8fZDLtz0vBhmXD+Ue+p71i0sqw0TfNs+DYvuneW7Bk0uy
TfNpaVRZp+xJgYukrNqZqXw7+O4OuqU5Y1X42CCoz8m6+Zxado1sOB6jeEQjyyqH
+Liewv0jas67velgycrNRG4O0ppoOUF8vVY26ofeWtV16otc9/Yuz6+iqGJOJgo=
=8mxV
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-11-08 20:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07  9:58 Jeff Law
2011-11-07 10:19 ` Jakub Jelinek
2011-11-07 10:21   ` Richard Guenther
2011-11-07 10:30     ` Richard Guenther
2011-11-07 19:20       ` Jeff Law
2011-11-07 16:14     ` Jeff Law
2011-11-07 16:30       ` Richard Guenther
2011-11-07 16:57         ` Kai Tietz
2011-11-07 19:03         ` Jeff Law
2011-11-08 11:50           ` Paolo Bonzini
2011-11-08 19:48             ` Jeff Law
2011-11-08 20:38               ` Paolo Bonzini
2011-11-08 20:59                 ` Jeff Law [this message]
2011-11-09  8:37                   ` Paolo Bonzini
2011-11-09 18:11                     ` Jeff Law
2011-11-09 18:12                       ` Jakub Jelinek
2011-11-09 22:45                       ` Paolo Bonzini
2011-11-10 19:27                         ` Jeff Law
2011-11-07 19:14   ` Jeff Law
2011-11-07 14:16 ` Tom Tromey
2011-11-07 15:54   ` Jeff Law
2011-11-07 15:54     ` Richard Guenther
2011-11-07 19:09       ` Jeff Law
2011-11-07 22:34         ` Richard Guenther
2011-11-08 20:02           ` Jeff Law
2011-11-09  9:50             ` Richard Guenther
2011-11-09 17:43               ` Jeff Law
2011-11-07 15:55     ` Tom Tromey
2011-11-07 17:01       ` Paolo Bonzini
2011-11-15  7:52         ` RFA: disable -fdelete-null-pointer-checks for Java Jeff Law
2011-11-07 19:05       ` RFA: New pass to delete unexecutable paths in the CFG Jeff Law

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=4EB99006.4060501@redhat.com \
    --to=law@redhat.com \
    --cc=bonzini@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /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).