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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to