possible gcse failure: not able to eliminate redundant loads
Alexandre Oliva
aoliva@redhat.com
Sat Dec 21 19:49:00 GMT 2002
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
More information about the Gcc
mailing list