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: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: davi...@google.com, era...@google.com,
fil...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, simon.f.whitta...@gmail.com,
tejohn...@google.com, xinlian...@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@cupiditate unroll]$ gcc -Os unroll.c -c -o unroll-gcc.o
[davide@cupiditate unroll]$ ../clang -Os unroll.c -c -o unroll-clang.o
[davide@cupiditate unroll]$ size unroll-gcc.o
text data bss dec hex filename
80 0 0 80 50 unroll-gcc.o
[davide@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
