This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: possible gcse failure: not able to eliminate redundant loads


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]