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

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.

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.

On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
> 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. :-)
This is something that LLVM isn't currently good at, but that we're  
actively interested in improving.  Here is some related stuff:
http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

I don't know of anyone working on this, or planning to work on it in  
the short term though.

-Chris

On 2009-09-06 20:52, Bill Wendling wrote:
> 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.
>   
Should LLVM IR inherit all that is undefined behavior in C?
That makes it harder to support other languages, or new languages that
want different semantics
for things that the C standard defines as undefined.

BTW even for C gcc has -fno-delete-null-pointer-checks, and the Linux
kernel started using that recently
by default after all the exploits that mapped NULL to valid memory, and
took advantage of
gcc optimizing away the NULL checks.


On 2009-09-06 23:22, Chris Lattner wrote:
> On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote:
>
>   
>> 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. :-)
>>     
>
> This is something that LLVM isn't currently good at, but that we're
> actively interested in improving.  Here is some related stuff:
> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>   
Looks interesting, but it also looks like a lot of work to implement.
Could instructions have a flag that says whether their semantics is
C-like (i.e. undefined behavior when you load from null etc.), or
something else? (throw exception, etc.).
Optimizations that assume the behavior is undefined should be updated to
check that flag, and perform the optimization only if the flag is set to
C-like.

What do you think?
> I don't know of anyone working on this, or planning to work on it in  
> the short term though.
>   

Although this is something I'd be interested in having, I lack the time
to implement it.

Best regards,
--Edwin