[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