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

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Sep 13 00:49:06 PDT 2019


            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:

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

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>

More information about the llvm-bugs mailing list