<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Performance degradation of eembc.1.1/idctrn01 test on x86 Avoton-1.7 due to adding of LICM pass after loop unrolling"
href="https://llvm.org/bugs/show_bug.cgi?id=23294">23294</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Performance degradation of eembc.1.1/idctrn01 test on x86 Avoton-1.7 due to adding of LICM pass after loop unrolling
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Loop Optimizer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>sergey.k.okunev@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>david.l.kreitzer@intel.com, denis.briltz@intel.com, elena.demikhovsky@intel.com, llvmbugs@cs.uiuc.edu, michael.m.kuperstein@intel.com, sergos.gnu@gmail.com, zia.ansari@intel.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=14231" name="attach_14231" title="Initial ll-file of considered 't_run_test' function">attachment 14231</a> <a href="attachment.cgi?id=14231&action=edit" title="Initial ll-file of considered 't_run_test' function">[details]</a></span>
Initial ll-file of considered 't_run_test' function
Bisect analysis showed LLVM revision 232011 is responsible for the
degradation. The comments to commit are the following.
commit a56999c5decca0023e5ce481fc08571e227e3aa3
Author: Kevin Qin <<a href="mailto:Kevin.Qin@arm.com">Kevin.Qin@arm.com</a>>
Date: Thu Mar 12 05:36:01 2015 +0000
Reapply 'Run LICM pass after loop unrolling pass.'
It's firstly committed at r231630, and reverted at r231635.
Function pass InstructionSimplifier is inserted as barrier to
make sure loop unroll pass won't affect on LICM pass.
git-svn-id: <a href="https://llvm.org/svn/llvm-project/llvm/trunk@232011">https://llvm.org/svn/llvm-project/llvm/trunk@232011</a>
91177308-0d34-0410-b5e6-96231b3b80d8
LLVM-clang options: O2 -ffast-math -m32 -mfpmath=sse -march=slm -fPIE –pie
The eembc_1_1/idctrn01 test has several hot loops with 3 levels of nesting (8 x
8 x 8 iterations). Each of these loops was fully unrolled. In adding the loop
invariant code motion pass (LICM) after the loop unroll pass (in r. 232011),
there are 16 loads hoisted up and the same 16 stores with constant addresses
sunk from the body of hot loop.
When machine specific code was generated for x86_32, AVT1.7 architecture these
16 loaded and stored values are transferred by stack spill, fill instructions
due to lack of xmm registers. As result additional loads and stores (fills and
spills) were generated inside, before and after loop in r232011 case. So, the
number of loads and stores inside loop are very close for both revisions and
‘additional’ loads and stores before and after loop cause the regression.
Changes enabled by considered revision in terms of simplified IR looks as
follows.
+16 <4 x i32> loads -> virt_regs1 !! hoisted up loads with const.
addr
br label %l_loop
%l_loop:
+16 <4 x i32> phi assignments
calculations (virt_regs1 / virt_regs2) !! loads and stores were
replaced by virtual regs
br %exitcond, label %l_exit, label %l_loop
%l_exit:
+16 <4 x i32> phi assignments
+16 virt_regs2 -> <4 x i32> stores !! sunk stores with const. addr
Corresponding asm loop code fragments with one load-store chain for two
revisions are the following.
r232010:
-------
xor %ecx,%ecx
; start of loop1
l_f772f5a0:
add $0x20,%ecx
movsbl -0x38(%eax),%edx
movdqu 0x2d0(%ebx),%xmm6 !! load with const addr. is inside loop
movd %edx,%xmm0
pshufd $0x0,%xmm0,%xmm2
pmulld %xmm2,%xmm3
paddd %xmm3,%xmm6
movdqu %xmm6,0x2d0(%ebx) !! store with const. addr. is inside loop
; ... and 15 more block like that ...
add $0x1,%eax
cmp $0x100,%ecx
jne l_f772f5a0 <t_run_test+0x840>
; end of loop1
vs.
r232011:
xor %ecx,%ecx
movdqu 0x2d0(%ebx),%xmm0 !! hoisted up load with const. addr
movdqa %xmm0,0xd0(%esp) !! spill-instr. before loop
; and 15 more movs like that
; start of loop1
l_f77c7680:
add $0x20,%ecx
movsbl -0x38(%eax),%edx
movdqa 0xd0(%esp),%xmm7 !! fill-instr. inside loop
movd %edx,%xmm2
pshufd $0x0,%xmm2,%xmm2
pmulld %xmm2,%xmm0
paddd %xmm0,%xmm7
movdqa %xmm7,0xd0(%esp) !! spill-instr. inside loop
; … and 15 more block like that …
add $0x1,%eax
cmp $0x100,%ecx
jne l_f77c7680 <t_run_test+0x920>
; end of loop1
movdqa 0xd0(%esp),%xmm0 !! fill-instr. after loop
movdqu %xmm0,0x2d0(%ebx) !! sunk stores with const. addr
; and 15 more movs like that
Okunev Sergey,
Software Engineer
Intel Compiler Team</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>