<div dir="ltr">Ok, not a full reproduction, but hopefully enough uploaded to <a href="http://llvm.org/PR37229">http://llvm.org/PR37229</a><div><br></div><div>This reproduces entirely with `llc` using the same IR input. It'll be LSR or some late IR loop pass, or it'll be a use of SCEV inside the code generator itself.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 25, 2018 at 12:33 AM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Unlikely to be either. Early signs are that the IR coming out of opt is identical and this happens somewhere later in the pipelien.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 25, 2018 at 12:28 AM Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="RU" link="blue" vlink="purple">
<div class="m_-2208761478224260288m_7289808338552182817WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">While you are working on reproducer, I've made two more shots in the dark in places where we seem to have incomplete invalidation:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://reviews.llvm.org/D46045" target="_blank">https://reviews.llvm.org/D46045</a><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://reviews.llvm.org/D46044" target="_blank">https://reviews.llvm.org/D46044</a>
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Please let me know if any of this helps!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></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:<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, April 25, 2018 2:18 PM</span></p></div></div><div lang="RU" link="blue" vlink="purple"><div class="m_-2208761478224260288m_7289808338552182817WordSection1"><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>To:</b> Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>><br>
<b>Cc:</b> Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>; Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>; <a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>; <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful<u></u><u></u></span></p></div></div><div lang="RU" link="blue" vlink="purple"><div class="m_-2208761478224260288m_7289808338552182817WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Yeah, I'm working on getting the IR and the before/after diff of the IR due to this patch. I have everything set up to compare.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Only one function changes too, gen_bitlen in trees.c, so it should be easy to get a "good" and "bad" IR test case both starting from some unoptimized bitcode.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Apr 25, 2018 at 12:08 AM Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>> wrote:<u></u><u></u></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>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Chandler,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Could you please send me the output of "clang -emit-llvm" before the optimizations are
happening? That would help me to investigate it on my side.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-- Max</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></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:<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, April 25, 2018 1:56 PM<br>
<b>To:</b> Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>><br>
<b>Cc:</b> Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>; Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>;
Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>;
<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>; <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">
llvm-commits@lists.llvm.org</a></span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Passing -O1 just to the compile of trees.c from zlib results in the failure:<u></u><u></u></p>
<div>
<p class="MsoNormal"><a href="https://github.com/madler/zlib/blob/master/trees.c" target="_blank">https://github.com/madler/zlib/blob/master/trees.c</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Looking at getting a before/after diff by reverting just this patch.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Apr 24, 2018 at 11:49 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Narrowing this down to a miscompile of zlib v1.2.11 which gets linked into Clang and which is used to compress and decompress the PCH file. This makes sense as the error is a corrupt
zlib header.<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Apr 24, 2018 at 11:21 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Just FYI, Clang appears to continue to miscompile itself on PPC after incorporating all of these fixes. I'll try narrow down what file.<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Apr 23, 2018 at 4:46 AM Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Fix is
<a href="https://reviews.llvm.org/D45945" target="_blank">https://reviews.llvm.org/D45945</a>
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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"> Maxim
Kazantsev <br>
<b>Sent:</b> Monday, April 23, 2018 5:02 PM<br>
<b>To:</b> 'Chandler Carruth' <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>><br>
<b>Cc:</b> Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>; Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>;
Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>;
<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>; <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">
llvm-commits@lists.llvm.org</a></span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> RE: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Here they have a reproducer on something that is very similar to that (and is not a duplicate):
<a href="https://bugs.llvm.org/show_bug.cgi?id=37205" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=37205</a>
</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I'm going to start looking at this.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<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 [<a href="mailto:chandlerc@gmail.com" target="_blank">mailto:chandlerc@gmail.com</a>]
</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Sent:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Monday,
April 23, 2018 4:56 PM<br>
<b>To:</b> Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>></span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Cc:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Chandler
Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>; Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>;
Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>;
<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>; <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">
llvm-commits@lists.llvm.org</a></span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">FWIW, I think it is OK to land some of these without explicit testing given the clear evidence that they could be problematic. It should also be reasonable to add test cases reduced
later from these failures if possible.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">But the easiest way for me to confirm whether these address the specific issue I've seen (but don't have a test case yet, nor know how to produce one easily) is to land the patches.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Apr 23, 2018 at 2:34 AM Maxim Kazantsev via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">One more place of potential problem is here:
<a href="https://reviews.llvm.org/D45940" target="_blank">https://reviews.llvm.org/D45940</a></span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Note that I don't have a test that would prove this leads to real miscompiles, and I'm
not sure how to construct it, but common sense says that invalidating parent alone is not enough.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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"> Maxim
Kazantsev <br>
<b>Sent:</b> Monday, April 23, 2018 1:05 PM</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>To:</b> 'Chandler Carruth' <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>; 'Kit Barton' <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; 'Eric Christopher' <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>;
'Han Shen' <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; 'Hal Finkel' <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>; '<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>' <<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>><br>
<b>Cc:</b> '<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>' <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Subject:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">
RE: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">At least one of this variety is real. It seems that some passes *do* expect that only
the innermost loop's cached data will be affected. I've submitted a fix for it: <a href="https://reviews.llvm.org/D45937" target="_blank">
https://reviews.llvm.org/D45937</a></span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I will keep looking for other issues of this kind. The symptom of the problem is that
SE.verify() fails at some point (which means that its internal data is inconsistent).</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hope it helps,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Max</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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"> Maxim
Kazantsev <br>
<b>Sent:</b> Monday, April 23, 2018 9:32 AM<br>
<b>To:</b> 'Chandler Carruth' <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>; 'Kit Barton' <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; 'Eric Christopher' <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>;
'Han Shen' <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; 'Hal Finkel' <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>; '<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>' <<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a>><br>
<b>Cc:</b> '<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>' <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br>
<b>Subject:</b> RE: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Actually I've started looking into the passes, and what happens in Loop Unswitching looks
highly suspicious:</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"> if (auto *SEWP = getAnalysisIfAvailable<ScalarEvolutionWrapperPass>())</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"> SEWP->getSE().forgetLoop(L);</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We are doing this before we start modifying the loop, in particular inserting new blocks.
It is pretty much like what was happening in unrolling. I haven't yet proved that it is a bug, but it is likely to be one. If you could disable loop unswitching and check if you still observe your failure without it, it would be very useful input.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Max</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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"> Maxim
Kazantsev <br>
<b>Sent:</b> Monday, April 23, 2018 8:26 AM<br>
<b>To:</b> 'Chandler Carruth' <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>; Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>;
Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>;
<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a><br>
<b>Cc:</b> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<b>Subject:</b> RE: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Chandler,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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).</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.
</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Please keep me informed on what you find!</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Best regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Max</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<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 [<a href="mailto:chandlerc@gmail.com" target="_blank">mailto:chandlerc@gmail.com</a>]
</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Sent:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Saturday,
April 21, 2018 10:20 AM<br>
<b>To:</b> Maxim Kazantsev <<a href="mailto:max.kazantsev@azul.com" target="_blank">max.kazantsev@azul.com</a>>; Kit Barton <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>>; Eric Christopher <<a href="mailto:echristo@google.com" target="_blank">echristo@google.com</a>>;
Han Shen <<a href="mailto:shenhan@google.com" target="_blank">shenhan@google.com</a>>; Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>;
<a href="mailto:dlj@google.com" target="_blank">dlj@google.com</a></span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Cc:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm] r329047 - [SCEV] Make computeExitLimit more simple and more powerful</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">This doesn't have anything to do with ASan FWIW, that just enables -O1.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Apr 20, 2018 at 7:20 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<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.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></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><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></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:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">We're seeing a miscompile with this that is ... really frustrating to pin down.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">error: 'error' diagnostics seen but not expected: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> (frontend): malformed or corrupted AST file: 'could not decompress embedded file contents: zlib error: Z_DATA_ERROR'<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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. =/<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">CC-ing various folks who may be able to help try to reproduce this usefully.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-Chandler<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">PS: Huge props to <a href="mailto:dlj@google.com" id="m_-2208761478224260288m_7289808338552182817m_8165347719213933599m_-537072350308214402m_-6229801664446921173m_-3175651114415680518m_-5583311505060217427m_7283480986174316125m_2032491058441245399IloFPc-0" target="_blank">+David
Jones</a> for pinning down the cause of this.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></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:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<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><u></u><u></u></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div></div></blockquote></div></blockquote></div>