[LLVMdev] loads from a null address and optimizations

[Chris Lattner]

On Sep 6, 2009, at 3:19 PM, Kenneth Uildriks wrote:
> On Sun, Sep 6, 2009 at 3:22 PM, Chris Lattner<clattner at apple.com>  
> 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
>
> Interesting.  What advantage do we get from the restriction that
> terminators (including invokes) can only appear at the end of a basic
> block?

The big advantage right now is that is how the CFG is constructed:  
pred_begin/succ_begin are based on the use/def chains of BasicBlocks,  
and they expect to have terminators.

However, while this is a nice and elegant solution, it will have to  
change in the future anyway.  Modeling the GCC "address of label and  
indirect goto" extension right requires breaking this as well.

>  We'd lose that advantage, but in one sense that advantage is
> already lost since loads, stores, calls, and whatnot *can* throw the
> path of execution out of the middle of a basic block, we just have no
> standard way to control or determine where it goes.

Well right now, we just claim it's undefined behavior :)

-Chris