llvm dev - Jun 2009 - [LLVMdev] Call to address 0 gets removed

> Dale Johannesen wrote:
>> Paul Schlie wrote:
>>> Dale Johannesen wrote:
>>>> Marius Wachtler wrote:
>>>> ...
>>>> The call to address 0 gets removed.
>>>> 
>>>> define i32 @t(i32 %a) noreturn nounwind readnone {
>>>> entry:
>>>>    unreachable
>>>> }
>>>> 
>>>> How can I prevent that the call is removed, without making the
>>>> function addr volatile?
>>>> Does anyone know which optimization removes it?
>>> 
>>> Calling 0 is undefined behavior; the optimizer is within its
>>> rights to remove this.  Why do you want to call 0?
>> 
>> Although a C translation unit may arguably not assign a
>> correspondingly defined function as having a pointer value
>> (address) comparing equal to ((void *) 0);
> 
> Nothing arguable about it, see C99 6.3.2.3
- yes agreed, however:
>> it's not clear that the standard forbids the invocation of such a
>> function
> 
> No such function can exist.  I don't think the standard forbids you
> to call 0, but it makes calling 0 undefined behavior ("behavior, upon
> use of a nonportable or erroneous program construct or of erroneous
> data"), since there can't possibly be a valid function there.
- also yes, however ((void *) 0) need not have a storage representation
  being equivalent to ((int) 0), as for example may be represented as
  being equivalent to ((int) -1) if desired (as may even be desirable
  in some circumstances); in which circumstance striping calls to "0"
  would arguably be wrong to broadly do. Although more practically as:
>> nor does it seem like a good idea to silently strip any such
>> invocations especially if allowed to be specified; as to do so
>> would seemingly only mask potentially legitimate problems, and/or
>> prevent that intended from being performed although potentially
>> relying on an undefined behavior.
>> 
>> (As for example, it's not hard to imagine that it may be desirable
>> to allow a machine which may trap such calls to do, and/or to allow
>> the invocation of some otherwise specified behavior although
>> considered undefined by standard itself.)
> 
> In general, a C compiler is not the right tool to use for
> functionality outside the C language, so I'm not inclined to be
> sympathetic to this line of reasoning.
- I presume you mean things like supporting inline assembly and a
  multitude of other other useful extensions which correspondingly
  have no have no well defined behavior? (a rhetorical question)

I understand you position, just simply don't agree that supporting
extensions which are useful and which do not violate the standard
are worthy of being broadly rejected, unless their specified undefined
behavior may be usefully capitalized upon to justify some more useful
optimization; however as stripping calls to "0", does not seem very
useful to anyone in practice, such calls may be more usefully preserved
possibly in combination with a useful non-portable warning. Merely IMHO.

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.

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.

John.

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>

On Jun 10, 2009, at 12:25 PM, John McCall wrote:
> 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.
For the default address space, LLVM IR *should* currently treat load/ 
store to null as an undefined operation.  To support Java-style  
"potentially trapping" load/store, we need something like this:
http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

-Chris