[llvm-bugs] [Bug 26532] New: don't unroll a loop that has no hope for improvement
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Feb 8 11:49:43 PST 2016
https://llvm.org/bugs/show_bug.cgi?id=26532
Bug ID: 26532
Summary: don't unroll a loop that has no hope for improvement
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedbugs at nondot.org
Reporter: spatel+llvm at rotateright.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
I'm not sure where this should be solved, but the "unroll-runtime" pass should
be reined in / less aggressive.
I was looking at the example in bug 25108 and wondered what happened with
simpler cases:
int foo(int x, int n) {
for (int i=0; i<n; i++)
x = x * x;
return x;
}
With:
$ ./clang -v
clang version 3.9.0 (trunk 260122)
Target: x86_64-apple-darwin15.3.0
$ ./clang -O2 25108.c -S -emit-llvm -o -
This gets unrolled 8x + prologue code. The net effect is that code which should
be simple like this (-Os or gcc 5.3 with -O2 is similar):
00 testl %esi, %esi
02 jle 0xb
04 imull %edi, %edi
07 decl %esi
09 jne 0x4
0b movl %edi, %eax
0d retq
...is bloated out to 64 bytes with almost no chance that this could be better
for performance on any recent x86:
00 testl %esi, %esi
02 jle 0x3d
04 leal -0x1(%rsi), %ecx
07 xorl %eax, %eax
09 movl %esi, %edx
0b andl $0x7, %edx
0e je 0x19
10 imull %edi, %edi
13 incl %eax
15 cmpl %eax, %edx
17 jne 0x10
19 cmpl $0x7, %ecx
1c jb 0x3d
1e subl %eax, %esi
20 imull %edi, %edi
23 imull %edi, %edi
26 imull %edi, %edi
29 imull %edi, %edi
2c imull %edi, %edi
2f imull %edi, %edi
32 imull %edi, %edi
35 imull %edi, %edi
38 addl $-0x8, %esi
3b jne 0x20
3d movl %edi, %eax
3f retq
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160208/4298de9f/attachment.html>
More information about the llvm-bugs
mailing list