[LLVMdev] loads from a null address and optimizations

Chris Lattner
Mon, 07 Sep 2009 15:24:05 -0000

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