[llvm-dev] Non-determinism in LLVM codegen

Duncan P. N. Exon Smith via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 15 17:08:43 PST 2016


> On 2016-Nov-15, at 15:16, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Mandeep Singh via llvm-dev Grang" <llvm-dev at lists.llvm.org>
>> To: llvm-dev at lists.llvm.org, "mehdi amini" <mehdi.amini at apple.com>, dexonsmith at apple.com, zinob at codeaurora.org
>> Sent: Tuesday, November 15, 2016 5:06:29 PM
>> Subject: [llvm-dev] Non-determinism in LLVM codegen
>> 
>> 
>> Everyone,
>> 
>> There is non-determinism in LLVM codegen in the following scenarios:
>> 
>> 1. Between back-to-back runs of the same LLVM toolchain
>> 2. Between Release vs Release+Asserts toolchains
>> 3. Between Linux vs Windows toolchains
>> 
>> The main reasons for the non-determinism in codegen are:
>> 
>> 1. Iteration of unordered containers (like SmallPtrSet, DenseMap,
>> etc) where the iteration order is undefined
>> 2. Use of non-stable sorts (like std:sort which uses quicksort) where
>> the relative order of elements with the same key is undefined
>> 
>> I wanted a way to uncover instances where iteration of unordered
>> containers results in different codegen.
>> So I have written the following patch:
>> https://reviews.llvm.org/D26703
>> 
>> Given a flag (-mllvm -reverse-iterate) this patch will enable
>> iteration of SmallPtrSet in reverse order. The idea is to compile
>> the same source with and without this flag and expect the code to
>> not change.
>> If there is a difference in codegen then it would mean that the
>> codegen is sensitive to the iteration order of SmallPtrSet.
>> 
>> I ran make check-all with and without my patch and I see the
>> following additional failures due to iteration of SmallPtrSet in
>> reverse order:
>> Clang :: Analysis/keychainAPI.m
>> Clang :: Analysis/malloc.c
>> Clang :: Rewriter/objc-modern-metadata-visibility.mm
>> Clang :: SemaCXX/warn-loop-analysis.cpp
>> LLVM :: Transforms/LoopVectorize/consecutive-ptr-uniforms.ll
>> LLVM :: Transforms/SimplifyCFG/bug-25299.ll
>> LLVM :: Transforms/Util/MemorySSA/cyclicphi.ll
>> LLVM :: Transforms/Util/MemorySSA/many-dom-backedge.ll
>> LLVM :: Transforms/Util/MemorySSA/many-doms.ll
>> LLVM :: Transforms/Util/MemorySSA/phi-translation.ll
>> 
>> I have posted the following patches which fix some of the above
>> failures by changing SmallPtrSet to SmallSetVector:
>> https://reviews.llvm.org/D26704
>> https://reviews.llvm.org/D26705
>> https://reviews.llvm.org/D26706
> 
> Great, thanks for working on this! Unfortunately, you did not subscribe llvm-commits when you created these, so the list did not receive the customary notification. Please re-post these subscribing llvm-commits so that we all get the notification.
> 
>> 
>> Here are the next steps which I would like to do:
>> 1. Replicate this patch for other containers (like DenseMap)
>> 2. Somehow enable reverse iteration in the lit framework for all
>> tests so that we can uncover these issues quickly
> 
> I'm not sure there is a good way of doing this, but we could certainly have a build mode which does this (and a buildbot running with that mode). I suspect we don't want to do this based on NDEBUG anyway to avoid ODR problems from external client code.

It would be possible to base this on LLVM_ENABLE_ABI_BREAKING_CHECKS instead of NDEBUG (there's a CMake option to control this).
- Asserts builds -DLLVM_ENABLE_ABI_BREAKING_CHECKS by default.
- No-asserts builds -ULLVM_ENABLE_ABI_BREAKING_CHECKS by default.
- Clients that mix-and-match Asserts/No-asserts can pick one or the other.

> 
> -Hal
> 
>> 
>> Please feel free to review my patch for reverse iteration. I would
>> welcome comments/suggestions for improving/extending the patch and
>> enabling it in lit.
>> 
>> Thanks,
>> Mandeep
>> 
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory



More information about the llvm-dev mailing list