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>