This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: possible gcse failure: not able to eliminate redundant loads
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: rth at redhat dot com, toon at moene dot indiv dot nluug dot nl, gcc at gcc dot gnu dot org
- Date: 21 Dec 2002 17:17:19 -0200
- Subject: Re: possible gcse failure: not able to eliminate redundant loads
- Organization: GCC Team, Red Hat
- References: <20021219012754.5F8D8F28D5@nile.gnat.com>
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