[llvm-bugs] [Bug 43305] New: larger code for std::max({a, b, c}) at -Os than at -O2

[via llvm-bugs]

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

            Bug ID: 43305
           Summary: larger code for std::max({a,b,c}) at -Os than at -O2
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Originally filed in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1002750

Consider the following example (see https://godbolt.org/z/jSMvrK)


#include <algorithm>

int testA(int a, int b, int c) {
  return std::max(std::max(a, b), c);
}

int testB(int a, int b, int c) {
  return std::max({a, b, c});
}

int main(int argc, char* argv[]) {
    return 0;
}


For testA, clang generates two cmov instructions, both at -Os and -O2.

For testB, clang generates the same two cmov instructions at -O2, but at -Os it
doesn't unroll the loop, leading to much larger code.


Could llvm figure out that unrolling the loop is beneficial for size in this
case?

Or would it help if libc++ defined std::max differently? It's unfortunate that
std::max({a, b, c}), which seems more elegant than std::max(std::max(a, b), c),
ends up with much larger code.

-- 
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/20190913/9818e2c7/attachment.html>