[llvm-bugs] [Bug 42024] New: [X86] Terrible codegen for 'splatting' memory copies

via llvm-bugs llvm-bugs at lists.llvm.org
Sun May 26 05:42:15 PDT 2019


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

            Bug ID: 42024
           Summary: [X86] Terrible codegen for 'splatting' memory copies
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm-dev at redking.me.uk
                CC: anton.a.afanasyev at gmail.com, craig.topper at gmail.com,
                    lebedev.ri at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, nikita.ppv at gmail.com,
                    spatel+llvm at rotateright.com

I'm reporting this in X86 as we may be able to resolve much of it with better
costs and/or shuffle combining but the issue probably needs some fixes in the
vectorizers - we can reassign as necessary.

By splatting memory copy I mean a 1:N copy of each element, e.g. from a
grayscale to RGB uint8_t image copy:

template <typename T>
void splat3_copy(size_t n, T* __restrict dst, const T* __restrict src) {
    for (size_t i = 0; i < n; ++i) {
        auto s = src[i];
        dst[3*i+0] = s;
        dst[3*i+1] = s;
        dst[3*i+2] = s;
    }
}
void splat3_copy8(size_t h, size_t w, unsigned char* __restrict dst, const
unsigned char* __restrict src) {
    splat3_copy(h * w, dst, src);
}

https://gcc.godbolt.org/z/8X-TrN

btver2 (AVX1) only uses individual byte loads + stores, while haswell (AVX2)
generates multiple vector loops of different sizes (with some pretty horrible
shuffles for what should be simple broadcasts+pshufb).

-- 
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/20190526/27b27a9e/attachment.html>


More information about the llvm-bugs mailing list