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

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

On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com>
wrote:
> 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".
What exactly would the semantics be if the instruction *might* trap?
I somehow can't imagine it being useful.

-Eli

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