[LLVMdev] loads from a null address and optimizations

[Bill Wendling]

The problem he's facing here isn't necessarily one of correctness.  
He's dealing with undefined behavior (at least in C code). There are  
no guarantees that the compiler will retain a certain semantic  
interpretation of an undefined construct between different versions of  
the compiler, let alone different optimization levels.

 From what I understand, he wants a particular behavior from the OS (a  
signal). The compiler shouldn't have to worry about OS semantics in  
the face of undefined language constructs. That being said, if he  
wants to implement a couple of passes to change his code, then sure. :-)

-bw

On Sep 6, 2009, at 10:22 AM, Kenneth Uildriks <kennethuil at gmail.com>  
wrote:

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