From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8406 invoked by alias); 9 Nov 2011 09:01:38 -0000 Received: (qmail 8392 invoked by uid 22791); 9 Nov 2011 09:01:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,TW_CF,TW_TM X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 09:01:00 +0000 Received: by qabj40 with SMTP id j40so1189299qab.20 for ; Wed, 09 Nov 2011 01:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.41 with SMTP id rx9mr305616obc.12.1320829259888; Wed, 09 Nov 2011 01:00:59 -0800 (PST) Received: by 10.182.17.232 with HTTP; Wed, 9 Nov 2011 01:00:59 -0800 (PST) In-Reply-To: <4EB98759.1070204@redhat.com> References: <4EB7AAF6.6060702@redhat.com> <4EB7FCAA.10100@redhat.com> <4EB82B89.7020208@redhat.com> <4EB98759.1070204@redhat.com> Date: Wed, 09 Nov 2011 09:50:00 -0000 Message-ID: Subject: Re: RFA: New pass to delete unexecutable paths in the CFG From: Richard Guenther To: Jeff Law Cc: Tom Tromey , gcc-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg01294.txt.bz2 On Tue, Nov 8, 2011 at 8:47 PM, Jeff Law wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/07/11 15:25, Richard Guenther wrote: >> >> Indeed. =A0We'd have to tell people that they cannot catch *(void *)0 >> =3D 0 with a SIGSEGV signal handler unless they compile with some >> magic flag. Thus, the question is whether we want to optimize >> things in a way that are non-obvious to people viewing things from >> a POSIX point of view rather than a C standard conforming issue. > Agreed. =A0The path I'd started going down was a flag like > "-fassume-null-dereference-faults-and-is-uncatchable" or something > like that. =A0-fdelete-null-pointer-checks =A0would be subsumed by the new > flag. > > >> >> >> But what we could do by default is transform such stores to a trap >> representation, or at least making the feeding stmts dead by >> changing the stored value and the address to a constant (thus, even >> preserve the trap kind). =A0fold_stmt could change the stored value >> if the address is literal zero, and all passes that know it is zero >> should propagate it anyway. =A0That wouldn't remove the outgoing edge >> from the store of course, cfgcleanup could be teached to do that >> though (and we could invent a trap kind argument to >> __builtin_trap). > More correctly, we'd wipe the path from the control edge to the *0 > statement and remove the out edges from the block with the *0. =A0Then > just leave the *0 or a __builtin_trap. > > We'd leave the control edge itself leading to the *0/trap. =A0That > allows us to get most of the space savings optimization as well as > most of the secondary benefits. =A0The programmer could still catch the > trapping signal. > > That doesn't work in the case of the implied dereference via =A0NULL PHI > arg. =A0For that case we'd have to copy the block with the PHI, the > incoming edges would be partitioned into those implying a null > dereference vs those not implying a null dereference. =A0Effectively > this isolates the path with the implied NULL dereference and turns it > into an explicit NULL dereference and we could optimize as noted above. Hm, indeed. > So the question is do we want to proceed with any of this work? =A0If so > I can update the patch, if not I'll go back to my warning work :-) I think we do want to continue with this work - probably not removing the faulting dereference though. I'd say we add a noreturn __builtin_nullptr_deref () in place of it (eventually doing the path isolation you mentioned above) and warn about the ones that survive until RTL expansion (where we'd just expand it as *0 =3D 0). In fact, the warning part of it might be the most useful piece for our user= s ;) Thanks, Richard.