[LLVMdev] loads from a null address and optimizations

Zoltan Varga vargaz at gmail.com
Sat Sep 5 14:59:33 PDT 2009


  I don't intentionally want to induce a tramp, the load null is created by
an llvm optimization
pass from code like:
   v = null;
   v.Call ();


On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com> wrote:

> Hi Zoltan,
> We've come across this before where people meant to induce a trap by
> dereferencing a null. It doesn't work for LLVM (as you found out).
> Essentially, it's a valid transformation to turn this into unreachable. The
> better solution is to use something like __builtin_trap.
> -bw
> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>                Hi,
>>  Currently, llvm treats the loads from a null address as unreachable code,
>> i.e.:
>>     load i32* null
>> is transformed by some optimization pass into
>>    unreachable
>> This presents problems in JIT compilers like mono which implement null
>> pointer checks by trapping SIGSEGV signals. It also
>> looks incorrect since it changes program behavior, which might be
>> undefined in general, but it is quite well defined on unix.
>> Is there a way to prevent llvm from doing this besides marking all loads
>> as volatile ?
>>                          thanks
>>                              Zoltan
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090905/31ae64a0/attachment.html>

More information about the llvm-dev mailing list