[llvm-bugs] [Bug 33128] New: Re-evaluate loop unrolling for size
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon May 22 10:47:24 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=33128
Bug ID: 33128
Summary: Re-evaluate loop unrolling for size
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedbugs at nondot.org
Reporter: davide at freebsd.org
CC: davidxl at google.com, eraman at google.com,
filcab at gmail.com, llvm-bugs at lists.llvm.org,
llvm-dev at redking.me.uk, simon.f.whittaker at gmail.com,
tejohnson at google.com, xinliangli at gmail.com
Currently, LLVM doesn't run `-loop-unroll` *at all* at -Os.
GCC, OTOH, does it, and this allows them to reduce the size of the generated
code, e.g. when unrolling loops with small (constant) trip counts:
https://godbolt.org/g/PpF4DG
extern int f(int);
int tinkywinky(void) {
int x;
for (int i = 0; i < 2; ++i) {
x += f(i);
}
return x;
}
[davide at cupiditate unroll]$ gcc -Os unroll.c -c -o unroll-gcc.o
[davide at cupiditate unroll]$ ../clang -Os unroll.c -c -o unroll-clang.o
[davide at cupiditate unroll]$ size unroll-gcc.o
text data bss dec hex filename
80 0 0 80 50 unroll-gcc.o
[davide at cupiditate unroll]$ size unroll-clang.o
text data bss dec hex filename
86 0 0 86 56 unroll-clang.o
We could also consider having this driven by profile informations to unroll
regions that are hot (and never touch regions that are cold). This has to make
conservative decisions as loop unrolling is an optimization that generally
increases the size of the final executable.
CC:ing some GCC/PGO experts for thoughts.
--
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/20170522/0a4525b2/attachment.html>
More information about the llvm-bugs
mailing list