[LLVMdev] Call to address 0 gets removed

[Nick Lewycky]

2009/6/10 John McCall <rjmccall at apple.com>

> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language.  I think you can make an excellent case that
> the standard optimizations should not be enforcing C language semantics,
> or at least should allow such optimizations to be disabled.


All sorts of optimizations rely on this, whether as simple as eliminating
comparisons of alloca against null to knowing that two malloc'd pointers can
never alias (what if malloc returns null? if null is valid then you can
store data there...).

Case in point — calls/loads/stores to null may be undefined behavior
> in C,
> but they're certainly not undefined behavior in (say) Java.  There's a
> well-
> known implementation trick in JVMs where you optimistically emit code
> assuming non-null objects, and then you install signal handlers to raise
> exceptions in the cases where you're wrong.  Now, obviously that trick
> is going to have implications for the optimizers beyond "don't mark null
> stores as unreachable" , but even so, it really shouldn't be totally
> precluded
> by widespread assumptions of C semantics.


The current workaround is to use an alternate address space for your
pointers. At some point we may extend the load/store/call instructions to
specify their exact semantics similarly to the integer overflow proposal (
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt ).

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/7f12b536/attachment.html>