[llvm-bugs] [Bug 47114] New: Excessive moves when returning array from nested struct

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Aug 11 05:21:21 PDT 2020


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

            Bug ID: 47114
           Summary: Excessive moves when returning array from nested
                    struct
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Support Libraries
          Assignee: unassignedbugs at nondot.org
          Reporter: alex.gaynor at gmail.com
                CC: llvm-bugs at lists.llvm.org

Extracted from: https://github.com/rust-lang/rust/issues/74267

Given the following C code, the `b` and `c` functions are behaviorally
identical (https://godbolt.org/z/5eKxE5):

#include <stdlib.h>
#include <stdint.h>

#define N 2

typedef struct {
    size_t length;
    size_t capacity;
    uint8_t* data;
} String;

static String new_string() {
    String s = {0, 0, NULL};
    return s;
}

struct Arr {
    String data[N];
};

struct Arr b() {
    struct Arr data;
    for (size_t i = 0; i < N; i++) {
        data.data[i] = new_string();
    }
    return data;
}

struct PartialArr {
    struct Arr value;
};

struct Arr c() {
    struct PartialArr data;
    String (*slots)[N] = &data.value.data;

    for (size_t i = 0; i < N; i++) {
        (*slots)[i] = new_string();
    }
    return data.value;
}




However, they end up optimized very differently:

b:                                      # @b
        mov     rax, rdi
        vxorps  xmm0, xmm0, xmm0
        vmovups xmmword ptr [rdi], xmm0
        mov     qword ptr [rdi + 16], 0
        vmovups xmmword ptr [rdi + 24], xmm0
        mov     qword ptr [rdi + 40], 0
        ret
c:                                      # @c
        vxorps  xmm0, xmm0, xmm0
        vmovaps xmmword ptr [rsp - 56], xmm0
        mov     qword ptr [rsp - 40], 0
        vmovups xmmword ptr [rsp - 32], xmm0
        mov     rax, rdi
        mov     qword ptr [rsp - 16], 0
        vmovups xmm0, xmmword ptr [rsp - 56]
        vmovups xmmword ptr [rdi], xmm0
        mov     rcx, qword ptr [rsp - 40]
        mov     qword ptr [rdi + 16], rcx
        mov     rcx, qword ptr [rsp - 32]
        mov     qword ptr [rdi + 24], rcx
        mov     rcx, qword ptr [rsp - 40]
        mov     qword ptr [rdi + 16], rcx
        vmovups xmm0, xmmword ptr [rsp - 32]
        vmovups xmmword ptr [rdi + 24], xmm0
        mov     rcx, qword ptr [rsp - 16]
        mov     qword ptr [rdi + 40], rcx
        ret


GCC is able to optimize this better:

b:
        mov     QWORD PTR [rdi], 0
        mov     QWORD PTR [rdi+8], 0
        mov     QWORD PTR [rdi+16], 0
        mov     QWORD PTR [rdi+24], 0
        mov     QWORD PTR [rdi+32], 0
        mov     QWORD PTR [rdi+40], 0
        mov     rax, rdi
        ret
c:
        mov     QWORD PTR [rdi], 0
        mov     QWORD PTR [rdi+8], 0
        mov     QWORD PTR [rdi+16], 0
        mov     QWORD PTR [rdi+24], 0
        mov     QWORD PTR [rdi+32], 0
        mov     QWORD PTR [rdi+40], 0
        mov     rax, rdi
        ret

-- 
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/20200811/1222a903/attachment-0001.html>


More information about the llvm-bugs mailing list