<div dir="ltr">Assuming that we get an option toggleable from clang (via an -mllvm flag or however), we could also consider adding a new check to clang/utils/check_cfc for this.  At Sony we've been using it very successfully to find codegen differences between -g and non-g builds using the 'dash_g_no_change' check.  Essentially put it on your path in place of the clang/clang++ executables and build test-suite/chromium/your project of choice as per normal.  Underneath it will build it in both modes and fail the compile if the resulting codegen they produce differs from each other.<div><br></div><div>See:</div><div><a href="http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf">http://llvm.org/devmtg/2015-04/slides/Verifying_code_gen_dash_g_final.pdf</a><br></div><div><br></div><div>-Greg</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2016 at 01:56, Grang, Mandeep Singh via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the suggestions!<br>
<br>
We can do this on LLVM_ENABLE_ABI_BREAKING_CHECK<wbr>S but we would still need to provide the user the capability to toggle the behavior via flag, right?<br>
Otherwise debugging issues would be difficult if reverse iteration cannot be turned ON/OFF dynamically.<span class="im HOEnZb"><br>
 < It would be possible to base this on LLVM_ENABLE_ABI_BREAKING_CHECK<wbr>S instead of NDEBUG (there's a CMake option to control this).<br>
< - Asserts builds -DLLVM_ENABLE_ABI_BREAKING_CHE<wbr>CKS by default.<br>
< - No-asserts builds -ULLVM_ENABLE_ABI_BREAKING_CHE<wbr>CKS by default.<br>
< - Clients that mix-and-match Asserts/No-asserts can pick one or the other.<br>
<br></span><span class="HOEnZb"><font color="#888888">
--Mandeep</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/15/2016 5:08 PM, Duncan P. N. Exon Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2016-Nov-15, at 15:16, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Mandeep Singh via llvm-dev Grang" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>, "mehdi amini" <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>>, <a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>, <a href="mailto:zinob@codeaurora.org" target="_blank">zinob@codeaurora.org</a><br>
Sent: Tuesday, November 15, 2016 5:06:29 PM<br>
Subject: [llvm-dev] Non-determinism in LLVM codegen<br>
<br>
<br>
Everyone,<br>
<br>
There is non-determinism in LLVM codegen in the following scenarios:<br>
<br>
1. Between back-to-back runs of the same LLVM toolchain<br>
2. Between Release vs Release+Asserts toolchains<br>
3. Between Linux vs Windows toolchains<br>
<br>
The main reasons for the non-determinism in codegen are:<br>
<br>
1. Iteration of unordered containers (like SmallPtrSet, DenseMap,<br>
etc) where the iteration order is undefined<br>
2. Use of non-stable sorts (like std:sort which uses quicksort) where<br>
the relative order of elements with the same key is undefined<br>
<br>
I wanted a way to uncover instances where iteration of unordered<br>
containers results in different codegen.<br>
So I have written the following patch:<br>
<a href="https://reviews.llvm.org/D26703" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2670<wbr>3</a><br>
<br>
Given a flag (-mllvm -reverse-iterate) this patch will enable<br>
iteration of SmallPtrSet in reverse order. The idea is to compile<br>
the same source with and without this flag and expect the code to<br>
not change.<br>
If there is a difference in codegen then it would mean that the<br>
codegen is sensitive to the iteration order of SmallPtrSet.<br>
<br>
I ran make check-all with and without my patch and I see the<br>
following additional failures due to iteration of SmallPtrSet in<br>
reverse order:<br>
Clang :: Analysis/keychainAPI.m<br>
Clang :: Analysis/malloc.c<br>
Clang :: Rewriter/<a href="http://objc-modern-metadata-visibility.mm" rel="noreferrer" target="_blank">objc-modern-metadata-<wbr>visibility.mm</a><br>
Clang :: SemaCXX/warn-loop-analysis.cpp<br>
LLVM :: Transforms/LoopVectorize/conse<wbr>cutive-ptr-uniforms.ll<br>
LLVM :: Transforms/SimplifyCFG/bug-252<wbr>99.ll<br>
LLVM :: Transforms/Util/MemorySSA/cycl<wbr>icphi.ll<br>
LLVM :: Transforms/Util/MemorySSA/many<wbr>-dom-backedge.ll<br>
LLVM :: Transforms/Util/MemorySSA/many<wbr>-doms.ll<br>
LLVM :: Transforms/Util/MemorySSA/phi-<wbr>translation.ll<br>
<br>
I have posted the following patches which fix some of the above<br>
failures by changing SmallPtrSet to SmallSetVector:<br>
<a href="https://reviews.llvm.org/D26704" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2670<wbr>4</a><br>
<a href="https://reviews.llvm.org/D26705" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2670<wbr>5</a><br>
<a href="https://reviews.llvm.org/D26706" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2670<wbr>6</a><br>
</blockquote>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here are the next steps which I would like to do:<br>
1. Replicate this patch for other containers (like DenseMap)<br>
2. Somehow enable reverse iteration in the lit framework for all<br>
tests so that we can uncover these issues quickly<br>
</blockquote>
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.<br>
</blockquote>
It would be possible to base this on LLVM_ENABLE_ABI_BREAKING_CHECK<wbr>S instead of NDEBUG (there's a CMake option to control this).<br>
- Asserts builds -DLLVM_ENABLE_ABI_BREAKING_CHE<wbr>CKS by default.<br>
- No-asserts builds -ULLVM_ENABLE_ABI_BREAKING_CHE<wbr>CKS by default.<br>
- Clients that mix-and-match Asserts/No-asserts can pick one or the other.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Hal<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please feel free to review my patch for reverse iteration. I would<br>
welcome comments/suggestions for improving/extending the patch and<br>
enabling it in lit.<br>
<br>
Thanks,<br>
Mandeep<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</blockquote></blockquote>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>