[llvm-bugs] [Bug 51084] New: Loop unroll may be too aggressive to unroll constant-trip-count loops, which could disable LSR

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51084

            Bug ID: 51084
           Summary: Loop unroll may be too aggressive to unroll
                    constant-trip-count loops, which could disable LSR
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: zsrkmyn at gmail.com
                CC: llvm-bugs at lists.llvm.org

We found that loop unroll pass may be too aggressive to unroll
constant-trip-count loops, which can disable LSR pass and generate inefficient
code.


Reproducer:

// test.c
#define SIZE (16*1024+4)
float a[SIZE];
void bar() {
#ifdef UNROLL64
# pragma unroll(64)
#else
# pragma unroll
#endif
  for (int i = 0; i < SIZE - 4; i++)
    a[i] = a[i + 4];
}


Command:
$ clang -O2 -fno-slp-vectorize -fno-vectorize -S -DUNROLL64 test.c -o -
$ clang -O2 -fno-slp-vectorize -fno-vectorize -S test.c -o -


When checking the output, we noticed that there's a lot unnecessary mov+or
instructions to calculate the index of the array when UNROLL64 is undefined.
See below.


# w/ UNROLL64
movss   -140(%rdi,%rax,4), %xmm0        # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, -156(%rdi,%rax,4)
movss   -136(%rdi,%rax,4), %xmm0        # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, -152(%rdi,%rax,4)
movss   -132(%rdi,%rax,4), %xmm0        # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, -148(%rdi,%rax,4)
movss   -128(%rdi,%rax,4), %xmm0        # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, -144(%rdi,%rax,4)
...

# w/o UNROLL64
movq    %rsi, %rcx
orq     $256, %rcx                      # imm = 0x100
movss   (%rdi,%rcx), %xmm0              # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, (%rdi,%rdx)
movq    %rsi, %rdx
orq     $260, %rdx                      # imm = 0x104
movss   (%rdi,%rdx), %xmm0              # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, (%rdi,%rbx)
movq    %rsi, %rbx
orq     $264, %rbx                      # imm = 0x108
movss   (%rdi,%rbx), %xmm0              # xmm0 = mem[0],zero,zero,zero
movss   %xmm0, (%rdi,%r9)
...



Triage note:

We noticed that these mov/or insts are eliminated in LSR pass, however, when
the unroll factor isn't specified, the loop is unrolled with count 2048 because
of a big partial unroll threshold (16*1024).

  // llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
  static cl::opt<unsigned> PragmaUnrollThreshold(
      "pragma-unroll-threshold", cl::init(16 * 1024),
  ...
  if (ExplicitUnroll && TripCount != 0) {
    // If the loop has an unrolling pragma, we want to be more aggressive with
    // unrolling limits. Set thresholds to at least the PragmaUnrollThreshold
    // value which is larger than the default limits.
    UP.Threshold = std::max<unsigned>(UP.Threshold, PragmaUnrollThreshold);
    UP.PartialThreshold =
        std::max<unsigned>(UP.PartialThreshold, PragmaUnrollThreshold);
  }


Then LSR just rejected to optimize the unrolled loop.

$ clang -O2 -fno-slp-vectorize -fno-vectorize -S test.c -emit-llvm -o - | opt
-loop-reduce -debug-only=loop-reduce -disable-output
LSR skipping loop, too many IV Users in 0x62c2f50

-- 
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/20210714/8f326826/attachment.html>