[LLVMdev] loads from a null address and optimizations

[Kenneth Uildriks]

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

It would be unfortunate in a way if "this instruction can trap and go
there" is taken to mean "if this instruction has no effect other than
a possible trap, the instruction and the trapping behavior *must* be
preserved".