[llvm-bugs] [Bug 35139] New: clang -flto doesn't respect -fno-unroll-loops option
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Oct 30 15:10:24 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=35139
Bug ID: 35139
Summary: clang -flto doesn't respect -fno-unroll-loops option
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangbugs at nondot.org
Reporter: st at quanttec.com
CC: llvm-bugs at lists.llvm.org
When I let clang link together object files that I produced with -flto -Os, the
link time optimization seems to respect the -Os option. When I let it link
files produced with -flto -O2 -fno-unroll-loops the -fno-unroll-loops flag
seems to be ignored.
Test case:
The following 3 commands produce an executable with an unrolled loop (using
clang 5.0 and the files pasted below; verified by disassembling the
executable):
> clang -flto -O2 -fno-unroll-loops -c loop.c -o loop.o
> clang -O2 -fno-unroll-loops -c main.c -o main.o
> clang -flto -O2 -fno-unroll-loops loop.o main.o -o main
I'd expect this to produce an executable without an unrolled loop, even when
the last command only reads `clang -flto loop.o main.o -o main`, as is the case
when using -Os instead of -O2 when compiling loop.c and main.c.
Adding `-Xlinker -mllvm -Xlinker -unroll-count=0` to the last command actually
does stop LLVM from unrolling the loop.
-- loop.c --
__attribute__((noinline))
int loop(float *array, int count) {
float i1 = 1;
for (int i = 0; i < count; ++i, i1 += 1) {
array[i] += i1;
}
return count;
}
-- loop.h --
int loop(float *array, int count);
-- main.c --
#include "loop.h"
int main() {
volatile int zero = 0;
return loop(0, zero);
}
--
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/20171030/46ea4f2f/attachment.html>
More information about the llvm-bugs
mailing list