[LLVMdev] loads from a null address and optimizations
clattner at apple.com
Mon Sep 7 08:24:05 PDT 2009
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>
>> 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
>>> 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
>> interested in improving. Here is some related stuff:
> Interesting. What advantage do we get from the restriction that
> terminators (including invokes) can only appear at the end of a basic
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 :)
More information about the llvm-dev