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

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>

Zoltan Varga wrote:
> 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 ();
This is more of a workaround than a solution, but have you tried 
emitting null as inttoptr(0) instead of a ConstantPointerNull?  That 
should disable optimizations relying on C-like undefined behavior 
semantics, at least as long as there isn't some pass which recognizes 
that pattern and turns it back into null.

John.

It's essentially the sane thing. :-) I don't quite understand the  
code. Is 'v' ever assigned a value before 'v.Call()'?

Two options remain, from what I can see. Either mark v as volatile, or  
compile without optimizations. The second is more drastic.

If you *really* want it to perform a call on null. Then you could  
place a function in another module that only returns null, then do the  
call:

// module A
typedef void (*func)();

func Foo() { return 0; }

// module B

Foo().Call();

And then make sure you don't perform LTO.

-bw

On Sep 5, 2009, at 4:59 PM, Zoltan Varga <vargaz at gmail.com> wrote:
> 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/91978212/attachment.html>

How about this:

1. A custom pass run at the beginning that inserts a null check before
every load/store:

if ( ptr == null )
  trap;

Then if any pointers get optimized to null, the if condition becomes a
constant true,and the trap call should become unconditional.

2. A custom pass at the end that takes out every remaining null check
that your first pass inserted.  It should first check whether the
condition is in fact a constant true (since that reduction might not
have been run after ptr became a constant null) and turn it into an
unconditional trap.

On Sat, Sep 5, 2009 at 4:59 PM, Zoltan Varga<vargaz at gmail.com>
wrote:
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

On Sun, Sep 6, 2009 at 6:52 AM, Kenneth Uildriks<kennethuil at gmail.com>
wrote:
> How about this:
>
> 1. A custom pass run at the beginning that inserts a null check before
> every load/store:
>
> if ( ptr == null )
>  trap;
>
> Then if any pointers get optimized to null, the if condition becomes a
> constant true,and the trap call should become unconditional.
>
> 2. A custom pass at the end that takes out every remaining null check
> that your first pass inserted.  It should first check whether the
> condition is in fact a constant true (since that reduction might not
> have been run after ptr became a constant null) and turn it into an
> unconditional trap.
On second thought...

You'd like the program to behave correctly (whatever you mean by that)
whether any optimization passes are run or not.  So have your
front-end emit the null-pointer checks with the explicit trap call,
and then you'll only need the pass at the end to take them out; but
leaving them in will still have your program behaving correctly,
although running a bit slower.