From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20845 invoked by alias); 21 Dec 2002 19:17:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20836 invoked from network); 21 Dec 2002 19:17:46 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 21 Dec 2002 19:17:46 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBLJHOY13316; Sat, 21 Dec 2002 14:17:27 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5) with ESMTP id gBLJHNeo005971; Sat, 21 Dec 2002 17:17:23 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5/Submit) id gBLJHKna005967; Sat, 21 Dec 2002 17:17:20 -0200 To: dewar@gnat.com (Robert Dewar) Cc: rth@redhat.com, toon@moene.indiv.nluug.nl, gcc@gcc.gnu.org Subject: Re: possible gcse failure: not able to eliminate redundant loads References: <20021219012754.5F8D8F28D5@nile.gnat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sat, 21 Dec 2002 19:49:00 -0000 In-Reply-To: <20021219012754.5F8D8F28D5@nile.gnat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg01311.txt.bz2 On Dec 18, 2002, dewar@gnat.com (Robert Dewar) wrote: > it is interesting to note that the IBM compiler group decided that > ensuring that null could be safetly dereferenced, and hence such > references can be hoisted etc, was a major win in C code efficiency. At the expense of getting nice crashes at points where NULL is dereferenced, which often makes it easy to find bugs? Oh, and there's also the issue that pointers with static storage, without an explicit initializer, are supposed to be zero-initialized, which, I suppose, means they get a NULL value. If NULL is a bit pattern that differs from all zeros, you become unable to place such symbols in sbss or, worse, you need dynamic initialization in case the address of the NULL object can only be known at run time (e.g. shared libraries). Ideally, we'd be able to mark would-trap dereferences hoisted out of their protecting conditions, and only actually trap should the condition hold. IA64 does that, but other platforms would require supporting code in the kernel or in signal handlers, whose overhead would probably defeat the performance win of being able to hoist the dereferences in the first place. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer