[LLVMdev] loads from a null address and optimizations

[Chris Lattner]

On Sep 6, 2009, at 2:01 PM, Török Edwin wrote:

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

Yes, where it is useful for optimization purposes.

> That makes it harder to support other languages, or new languages that
> want different semantics
> for things that the C standard defines as undefined.

This is another question though.  I think that LLVM should support  
taking advantage of undefined behavior in C, but it should also allow  
other languages to model what they need.

As a concrete example, there is no reason not to add a "bit" to  
LoadInst saying whether an "invalid" load is undefined or whether it  
causes an "exception".  The fun part is nailing down which cases of  
"invalid" are allowed, but it isn't that big of a deal.

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

Well that is why it hasn't been done yet :)

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

Yes.  You need to tell the optimizer what the possible control flow is  
though, or else it will move operations in invalid ways.

> What do you think?

Right!

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090907/4624565a/attachment.html>