<html><body>
<p><img width="16" height="16" src="cid:1__=0ABBF417DFDD0FEF8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Chandler Carruth ---07/15/2015 08:35:09 PM---On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung <hsung@us.i"><font size="2" color="#424282" face="sans-serif">Chandler Carruth ---07/15/2015 08:35:09 PM---On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung <hsung@us.ibm.com> wrote: > Hi all,</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Chandler Carruth <chandlerc@google.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Hyojin Sung/Watson/IBM@IBMUS, llvmdev@cs.uiuc.edu</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">07/15/2015 08:35 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung <</font><a href="mailto:hsung@us.ibm.com"><font size="3" color="#0000FF" face="serif"><u>hsung@us.ibm.com</u></font></a><font size="3" face="serif">> wrote:</font>
<ul style="padding-left: 9pt"><font size="2" face="Helvetica">Hi all,</font><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
I would like to propose an improvement of the “almost dead” block elimination in Transforms/Local.cpp so that it will preserve the canonical loop form for loops with a volatile iteration variable.</font><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
*** Problem statement<br>
Nested loops in LCALS Subset B (</font><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__codesign.llnl.gov_LCALS.php&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=aWKfvN4c8lvUSvVn8J0Z2ajTctlBJf0198Au28epBr0&s=4d9dt5ODcDWHHatSrwu5ZYT9ebgVzNEtpOlIR87izCM&e=" target="_blank"><font size="2" color="#0000FF" face="Helvetica"><u>https://codesign.llnl.gov/LCALS.php</u></font></a><font size="2" face="Helvetica">) are not vectorized with LLVM -O3 because the LLVM loop vectorizer fails the test whether the loop latch and exiting block of a loop is the same. The loops are vectorizable, and get vectorized with LLVM -O2</font></ul>
<br>
<font size="3" face="serif">I would be interested to know why -O2 succeeds here.</font>
<p><font size="3" face="serif">-O2 does not perform loop unswitching which creates artificial empty placeholder blocks in the outer loop. As long as incrementing and testing the volatile iteration variable is kept only in the original BB, the block does not get eliminated. </font><br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><font size="2" face="Helvetica">and also with other commercial compilers (icc, xlc). </font><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
*** Details<br>
These loops ended up with different loop latch and exiting block after a series of optimizations including loop unswitching, jump threading, simplify-the-CFG, and loop simplify. The fundamental problem here is that the above optimizations cannot recognize a loop with a volatile iteration variable and do not preserve its canonical loop structure.</font></ul>
<br>
<font size="3" face="serif">Ok, meta-level question first:</font><br>
<br>
<font size="3" face="serif">Why do we care about performance of loops with a volatile iteration variable? That seems both counter-intuitive and unlikely to be a useful goal. We simply don't optimize volatile operations well in *any* part of the optimizer, and I'm not sure why we need to start trying to fix that. This seems like an irreparably broken benchmark, but perhaps there is a motivation I don't yet see.</font><br>
<br>
<br>
<font size="3" face="serif">Assuming that sufficient motivation arises to try to fix this, see my comments below:</font><br>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
(1) Loop unswitching generates several empty placeholder BBs only with PHI nodes after separating out a shorter path with no inner loop execution from a standard path. </font><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
(2) Jump threading and simplify-the-CFG passes independently calls TryToSimplifyUnconditionalBranchFromEmptyBlock() in Transforms/Utils/Local.cpp to get rid of almost empty BBs. </font><font size="3" face="serif"><br>
</font><font size="2" face="Helvetica"><br>
(3) TryToSimplifyUnconditionalBranchFromEmtpyBlock() eliminates the placeholder BBs after loop unswitching and merges them into subsequent blocks including the header of the inner loop. Before eliminating the blocks, the function checks if the block is a loop header by looking at its PHI nodes so that it can be saved, but the test fails with the loops with a volatile iteration variable.</font></ul>
<br>
<font size="3" face="serif">Why does this fail for a volatile iteration variable but not for a non-volatile one? I think understanding that will be key to understanding how it should be fixed.</font>
<p>
<p></body></html>