On Sat, Sep 7, 2013 at 4:47 PM, Geoffrey Irving <[email protected]> wrote:
> On Sep 7, 2013, at 1:42 PM, Daniel Micay <[email protected]> wrote: > > > On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving <[email protected]> wrote: > > > > On Sep 7, 2013, at 1:32 PM, Daniel Micay <[email protected]> wrote: > > > > > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving <[email protected]> > wrote: > > > To clarify why undefined behavior is really bad in practice: if LLVM > ever detects that your code performs undefined behavior according to the > standard, it is *designed* to take full advantage of that fact when making > optimizations. In other words, all hell will break lose, in potentially > very complicated and subtle ways. > > > > > > Geoffrey > > > > > > Note that there's no detection of undefined behaviour or optimizations > based upon it being detected. LLVM simply operates on valid LLVM bytecode, > and if it performs undefined behaviour it is not valid LLVM bytecode. The > optimization passes and code generation will base all of their assumptions > on the invariants provided by the specification, including that null > pointers are never dereferenced. > > > > That may be true; I got the opposite impression from this article: > > > > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html > > > > Geoffrey > > > > You're getting a very wrong impression if you think it optimizes based > on those assumptions only when it can detect undefined behaviour. It > completely ignores the possibility of undefined behaviour in the > optimization passes by assuming all of the invariants required for the > bytecode to be valid hold true. > > > > The `-fcatch-undefined-behaviour` switch inserts runtime checks. > > I think we're saying the same thing: I didn't intend to imply that it > optimizes based on those assumptions only if it can prove that undefined > behavior never occurs. If it detects undefined behavior along certain > paths, it will assume those paths can never occur, and then propagate those > assumptions backwards through the program in an attempt to make > simplifications. Thus, a null pointer access somewhere could easily > complete a weirdly incorrect assumption causing a previous branch to be > taken incorrectly. > > Geoffrey > Ah okay, we're on the same page then :).
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
