<div class="gmail_quote">2009/6/10 John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Case in point — calls/loads/stores to null may be undefined behavior<br>
in C,<br>
but they're certainly not undefined behavior in (say) Java.  There's a<br>
well-<br>
known implementation trick in JVMs where you optimistically emit code<br>
assuming non-null objects, and then you install signal handlers to raise<br>
exceptions in the cases where you're wrong.  Now, obviously that trick<br>
is going to have implications for the optimizers beyond "don't mark null<br>
stores as unreachable" , but even so, it really shouldn't be totally<br>
precluded<br>
by widespread assumptions of C semantics.</blockquote><div><br>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 ( <a href="http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt">http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt</a> ).<br>

</div></div><br>Nick<br><br>