[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