llvm dev - Sep 2009 - [LLVMdev] loads from a null address and optimizations

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090905/3cb32915/attachment.html>

Zoltan Varga 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 ?
The other way is to use a custom (ie., non-zero) address space for your 
pointers. I'm not sure what the backend will do with these, but the 
optimizers know not to treat load/store from null as special in 
alternate address spaces. You may have to teach the backend to ignore 
your addrspace though.

Nick

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

Hi,

  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 ();

            Zoltan

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>