[llvm-dev] How and where optimizing of undefined behavior happens

John Regehr via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 19 13:43:10 PST 2017

On 11/19/17 5:13 AM, David Chisnall wrote:
> On 18 Nov 2017, at 20:55, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> By default, Clang has little or nothing to do with UB, its job is to do a straightforward translation to IR.
> That’s not quite true, because the mapping to IR helps define what is UB in the source language.  For example, if you don’t enable the undefined behaviour sanitiser or pass -ftrapv / -fwrapv, clang will set the nsw (no signed wrap) flag on IR arithmetic operations on types that are signed in C, which then permits the optimisers to treat wrapping behaviour as undefined.

Sure, and also the frontend eliminates probably 50-100 
preprocessor/parser/lexer-related UBs.  But I was trying answer what I 
understood the OP to be actually asking, which is where the real action 
happens, and that's to a large extent spread across the middle-end 
optimization passes.


More information about the llvm-dev mailing list