[llvm-bugs] [Bug 40066] New: Failed access analysis and missing vectorization of loop containing std::min/std::max

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 18 02:14:18 PST 2018


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

            Bug ID: 40066
           Summary: Failed access analysis and missing vectorization of
                    loop containing std::min/std::max
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: moritz.kreutzer at siemens.com
                CC: llvm-bugs at lists.llvm.org

Hi,

Clang trunk fails to vectorize the following loop with "cannot identify array
bounds":

    for (int i = 0; i < end; ++i) // does not vectorize
    {
        dst[i] = std::min(dst[i], dst[i]/src[i]);
    }

If we don't use std::min, but a simple ternary operator, Clang is able to
vectorize the resulting loop:

    for (int i = 0; i < end; ++i) // vectorizes
    {
        dst[i] = dst[i] < dst[i]/src[i] ? dst[i] : dst[i]/src[i];
    }

The problem does not seem to be std::min in itself, because Clang is able to
vectorize the following loop (note the different logic and the absence of an
implicit temporary for dst[i]/src[i]):

    for (int i = 0; i < end; ++i) // vectorizes
    {
        dst[i] = std::min(dst[i], src[i]);
    }

If we replace std::min with a custom implementation, returning the result by
value instead of "const &" (as it is done in libstdc++), we can also get the
first version to vectorize.

Obligatory godbolt: https://godbolt.org/z/6xjhz-

All in all, it seems like mixing references and values is the problem here. I
have tried patching D23686, D52116, and D52117, to no avail. From my feeling,
the first loop is something which should be vectorizable, even with the default
implementation of std::min (return a const reference ) in libstdc++ (in the
end, the call should be inlined and the compiler should be able to see through
everything). But maybe I'm missing something obvious, so any help is greatly
appreciated.


Thanks in advance,
Moritz

-- 
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/20181218/43044465/attachment.html>


More information about the llvm-bugs mailing list