[LLVMdev] loads from a null address and optimizations

Kenneth Uildriks kennethuil at gmail.com
Sun Sep 6 04:52:26 PDT 2009


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
>
>




More information about the llvm-dev mailing list