<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="RU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Hi Chandler,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Thank you very much for getting me informed! I'd be happy to help to deal with this issue. Please provide exact steps
for reproducing this issue once you track them down (I don't typically work with Clang and might need some links or instructions how to build the configuration you are mentioning).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">As for my suspicions (it is just a shot in the dark, I don't have solid arguments that this is exactly what is going on)
is that some pass, likely close to backend, is misusing SCEV. We can end up with memory corruption if some optimization doesn't invoke "forgetLoop" for a loop it might have modified somehow. The old code could be just accidentally correct just because we could
not compute anything for a loop which we failed to invalidate. In this case, it is something that must be fixed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Fortunately, there is not so many places where forgetLoop is used. I will now go through them and try to see what could
be wrong in how it's done there. With the patch under suspicion, we calculate exit counts for more loops now.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Please keep me informed on what you find!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Max<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Chandler Carruth [mailto:chandlerc@gmail.com]
<br>
<b>Sent:</b> Saturday, April 21, 2018 10:20 AM<br>
<b>To:</b> Maxim Kazantsev <max.kazantsev@azul.com>; Kit Barton <kbarton@ca.ibm.com>; Eric Christopher <echristo@google.com>; Han Shen <shenhan@google.com>; Hal Finkel <hfinkel@anl.gov>; dlj@google.com<br>
<b>Cc:</b> llvm-commits@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">This doesn't have anything to do with ASan FWIW, that just enables -O1.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Essentially, we're seeing this test fail on a "normal" bootstrapped Clang with -O1 (or -O2) after this revision. But weirdly, the 3-stage PPC build bot isn't failing. Trying to figure out why next.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Apr 20, 2018 at 7:20 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">In case it wasn't clear, I have no reason to suspect the code in this commit is wrong. We've looked at it and the code looks totally fine.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Much more likely that it is exposing some underlying bug somewhere much like the one fixed here: <a href="https://reviews.llvm.org/D44818" target="_blank">https://reviews.llvm.org/D44818</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Apr 20, 2018 at 7:19 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">We're seeing a miscompile with this that is ... really frustrating to pin down.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Specifically, it appears that if you build Clang itself using a Clang built after this revision (so a stage2 Clang binary in bootstrap parlance), and specifically build Clang itself with ASan enabled targeting PPC (no other architectures
we test in this way appear to be impacted), and then use that asan+ppc stage2 Clang binary to run a specific OpenMP test (clang/test/OpenMP:for_simd_codegen.cpp), that test will fail. It will specifically fail the third RUN line with the output:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">error: 'error' diagnostics seen but not expected: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> (frontend): malformed or corrupted AST file: 'could not decompress embedded file contents: zlib error: Z_DATA_ERROR'<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It is possible we have a miscompiled zlib after this revision? Haven't yet pinned down whether the *write* of the PCH just above it wrote corrupt data, or the *read* failed to read perfectly correct data.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sadly, I don't have access to a PPC machine to easily reproduce this and test these things out. We just have an automated build that happens to use this configuration and spits out the failure. =/<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">CC-ing various folks who may be able to help try to reproduce this usefully.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Somewhat concerning is that this is the *only* failure we've seen testing past this revision. No other platform, no other test. Doesn't fail w/o ASan, etc etc. But it also is really reliable on our end.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If anyone is trying to reproduce this, happy to chat with them on IRC and try to give the exact commands used at each stage of this.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Chandler<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">PS: Huge props to <a href="mailto:dlj@google.com" target="_blank" id="m_7283480986174316125m_2032491058441245399IloFPc-0">+David Jones</a> for pinning down the cause of this.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Apr 2, 2018 at 11:00 PM Max Kazantsev via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Author: mkazantsev<br>
Date: Mon Apr 2 22:57:19 2018<br>
New Revision: 329047<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=329047&view=rev" target="_blank">
http://llvm.org/viewvc/llvm-project?rev=329047&view=rev</a><br>
Log:<br>
[SCEV] Make computeExitLimit more simple and more powerful<br>
<br>
Current implementation of `computeExitLimit` has a big piece of code<br>
the only purpose of which is to prove that after the execution of this<br>
block the latch will be executed. What it currently checks is actually a<br>
subset of situations where the exiting block dominates latch.<br>
<br>
This patch replaces all these checks for simple particular cases with<br>
domination check over loop's latch which is the only necessary condition<br>
of taking the exiting block into consideration. This change allows to<br>
calculate exact loop taken count for simple loops like<br>
<br>
for (int i = 0; i < 100; i++) {<br>
if (cond) {...} else {...}<br>
if (i > 50) break;<br>
. . .<br>
}<br>
<br>
Differential Revision: <a href="https://reviews.llvm.org/D44677" target="_blank">
https://reviews.llvm.org/D44677</a><br>
Reviewed By: efriedma<br>
<br>
Modified:<br>
llvm/trunk/lib/Analysis/ScalarEvolution.cpp<br>
llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll<br>
<br>
Modified: llvm/trunk/lib/Analysis/ScalarEvolution.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/ScalarEvolution.cpp?rev=329047&r1=329046&r2=329047&view=diff" target="_blank">
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/ScalarEvolution.cpp?rev=329047&r1=329046&r2=329047&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/lib/Analysis/ScalarEvolution.cpp (original)<br>
+++ llvm/trunk/lib/Analysis/ScalarEvolution.cpp Mon Apr 2 22:57:19 2018<br>
@@ -6884,63 +6884,12 @@ ScalarEvolution::computeBackedgeTakenCou<br>
ScalarEvolution::ExitLimit<br>
ScalarEvolution::computeExitLimit(const Loop *L, BasicBlock *ExitingBlock,<br>
bool AllowPredicates) {<br>
- // Okay, we've chosen an exiting block. See what condition causes us to exit<br>
- // at this block and remember the exit block and whether all other targets<br>
- // lead to the loop header.<br>
- bool MustExecuteLoopHeader = true;<br>
- BasicBlock *Exit = nullptr;<br>
- for (auto *SBB : successors(ExitingBlock))<br>
- if (!L->contains(SBB)) {<br>
- if (Exit) // Multiple exit successors.<br>
- return getCouldNotCompute();<br>
- Exit = SBB;<br>
- } else if (SBB != L->getHeader()) {<br>
- MustExecuteLoopHeader = false;<br>
- }<br>
-<br>
- // At this point, we know we have a conditional branch that determines whether<br>
- // the loop is exited. However, we don't know if the branch is executed each<br>
- // time through the loop. If not, then the execution count of the branch will<br>
- // not be equal to the trip count of the loop.<br>
- //<br>
- // Currently we check for this by checking to see if the Exit branch goes to<br>
- // the loop header. If so, we know it will always execute the same number of<br>
- // times as the loop. We also handle the case where the exit block *is* the<br>
- // loop header. This is common for un-rotated loops.<br>
- //<br>
- // If both of those tests fail, walk up the unique predecessor chain to the<br>
- // header, stopping if there is an edge that doesn't exit the loop. If the<br>
- // header is reached, the execution count of the branch will be equal to the<br>
- // trip count of the loop.<br>
- //<br>
- // More extensive analysis could be done to handle more cases here.<br>
- //<br>
- if (!MustExecuteLoopHeader && ExitingBlock != L->getHeader()) {<br>
- // The simple checks failed, try climbing the unique predecessor chain<br>
- // up to the header.<br>
- bool Ok = false;<br>
- for (BasicBlock *BB = ExitingBlock; BB; ) {<br>
- BasicBlock *Pred = BB->getUniquePredecessor();<br>
- if (!Pred)<br>
- return getCouldNotCompute();<br>
- TerminatorInst *PredTerm = Pred->getTerminator();<br>
- for (const BasicBlock *PredSucc : PredTerm->successors()) {<br>
- if (PredSucc == BB)<br>
- continue;<br>
- // If the predecessor has a successor that isn't BB and isn't<br>
- // outside the loop, assume the worst.<br>
- if (L->contains(PredSucc))<br>
- return getCouldNotCompute();<br>
- }<br>
- if (Pred == L->getHeader()) {<br>
- Ok = true;<br>
- break;<br>
- }<br>
- BB = Pred;<br>
- }<br>
- if (!Ok)<br>
- return getCouldNotCompute();<br>
- }<br>
+ assert(L->contains(ExitingBlock) && "Exit count for non-loop block?");<br>
+ // If our exiting block does not dominate the latch, then its connection with<br>
+ // loop's exit limit may be far from trivial.<br>
+ const BasicBlock *Latch = L->getLoopLatch();<br>
+ if (!Latch || !DT.dominates(ExitingBlock, Latch))<br>
+ return getCouldNotCompute();<br>
<br>
bool IsOnlyExit = (L->getExitingBlock() != nullptr);<br>
TerminatorInst *Term = ExitingBlock->getTerminator();<br>
@@ -6955,9 +6904,19 @@ ScalarEvolution::computeExitLimit(const<br>
/*ControlsExit=*/IsOnlyExit, AllowPredicates);<br>
}<br>
<br>
- if (SwitchInst *SI = dyn_cast<SwitchInst>(Term))<br>
+ if (SwitchInst *SI = dyn_cast<SwitchInst>(Term)) {<br>
+ // For switch, make sure that there is a single exit from the loop.<br>
+ BasicBlock *Exit = nullptr;<br>
+ for (auto *SBB : successors(ExitingBlock))<br>
+ if (!L->contains(SBB)) {<br>
+ if (Exit) // Multiple exit successors.<br>
+ return getCouldNotCompute();<br>
+ Exit = SBB;<br>
+ }<br>
+ assert(Exit && "Exiting block must have at least one exit");<br>
return computeExitLimitFromSingleExitSwitch(L, SI, Exit,<br>
/*ControlsExit=*/IsOnlyExit);<br>
+ }<br>
<br>
return getCouldNotCompute();<br>
}<br>
<br>
Modified: llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll?rev=329047&r1=329046&r2=329047&view=diff" target="_blank">
http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll?rev=329047&r1=329046&r2=329047&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll (original)<br>
+++ llvm/trunk/test/Analysis/ScalarEvolution/exact_iter_count.ll Mon Apr 2 22:57:19 2018<br>
@@ -25,3 +25,37 @@ exit:<br>
side.exit:<br>
ret void<br>
}<br>
+<br>
+define void @test_02(i1 %c) {<br>
+<br>
+; CHECK-LABEL: Determining loop execution counts for: @test_02<br>
+; CHECK-NEXT: Loop %loop: <multiple exits> backedge-taken count is 50<br>
+<br>
+entry:<br>
+ br label %loop<br>
+<br>
+loop:<br>
+ %iv = phi i32 [ 0, %entry ], [ %iv.next, %backedge ]<br>
+ br i1 %c, label %if.true, label %if.false<br>
+<br>
+if.true:<br>
+ br label %merge<br>
+<br>
+if.false:<br>
+ br label %merge<br>
+<br>
+merge:<br>
+ %side.cond = icmp slt i32 %iv, 50<br>
+ br i1 %side.cond, label %backedge, label %side.exit<br>
+<br>
+backedge:<br>
+ %iv.next = add i32 %iv, 1<br>
+ %loop.cond = icmp slt i32 %iv, 100<br>
+ br i1 %loop.cond, label %loop, label %exit<br>
+<br>
+exit:<br>
+ ret void<br>
+<br>
+side.exit:<br>
+ ret void<br>
+}<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</body>
</html>