[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.
John
More information about the llvm-dev
mailing list