[LLVMdev] loads from a null address and optimizations
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
if ( ptr == null )
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
On Sat, Sep 5, 2009 at 4:59 PM, Zoltan Varga<vargaz at gmail.com> wrote:
> 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.
>> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>> Currently, llvm treats the loads from a null address as unreachable
>>> code, i.e.:
>>> load i32* null
>>> is transformed by some optimization pass into
>>> 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 ?
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev