[Bug other/50384] New: Copying a char array

[Bug other/50384] New: Copying a char array

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384

             Bug #: 50384
           Summary: Copying a char array
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marc.glisse@normalesup.org


#include <array>
typedef std::array<char,7> X;
X f(X,X);
X g(X a,X b){return f(a,b);}

I compiled this code on x86_64 with g++ -std=c++0x -Ofast and got:

_Z1gSt5arrayIcLm7EES0_:
.LFB837:
    .cfi_startproc
    pushq    %rbx
    .cfi_def_cfa_offset 16
    subq    $48, %rsp
    .cfi_def_cfa_offset 64
    .cfi_offset 3, -16
    call    _Z1fSt5arrayIcLm7EES0_
    movzbl    %ah, %edx
    movb    %al, (%rsp)
    movb    %dl, 1(%rsp)
    movq    %rax, %rdx
    shrq    $16, %rdx
    movb    %dl, 2(%rsp)
    movq    %rax, %rdx
    shrq    $24, %rdx
    movb    %dl, 3(%rsp)
    movq    %rax, %rdx
    movl    (%rsp), %ecx
    shrq    $32, %rdx
    movb    %dl, 4(%rsp)
    movq    %rax, %rdx
    shrq    $40, %rdx
    movl    %ecx, %esi
    movzbl    %cl, %ebx
    movb    %dl, 5(%rsp)
    movl    %ecx, %edx
    movzwl    4(%rsp), %edi
    shrl    $16, %edx
    movzbl    %ch, %ecx
    shrl    $24, %esi
    movzbl    %dl, %edx
    movb    %cl, %bh
    movzbl    %sil, %esi
    salq    $16, %rdx
    salq    $24, %rsi
    movabsq    $-1095216660481, %rcx
    orq    %rbx, %rdx
    movq    %rdi, %rbx
    addq    $48, %rsp
    .cfi_def_cfa_offset 16
    orq    %rsi, %rdx
    movzbl    %dil, %esi
    salq    $32, %rsi
    andq    %rcx, %rdx
    movzbl    %bh, %ecx
    orq    %rsi, %rdx
    movabsq    $-280375465082881, %rsi
    salq    $40, %rcx
    andq    %rsi, %rdx
    orq    %rcx, %rdx
    movabsq    $71776119061217280, %rcx
    andq    %rcx, %rax
    movabsq    $-71776119061217281, %rcx
    andq    %rcx, %rdx
    orq    %rax, %rdx
    movq    %rdx, %rax
    popq    %rbx
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc

Ideally I would have liked a single jmp, but in any case this seems a bit
long... (the attribute((aligned)) in versions <= 4.2 did help)
Is that the best that can legally be done without alignment information?

[Bug other/50384] Copying a char array

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384

--- Comment #1 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-14 08:23:15 UTC ---
Don't know if it is the same problem, but gcc seems to have trouble optimizing
with structs:

//typedef struct A { unsigned char t; } A;
typedef unsigned char A;
extern A f(A,A);
A g(A x,A y){ return f(y,x); }

Gives a nice:
    movzbl    %dil, %eax
    movzbl    %sil, %edi
    movl    %eax, %esi
    jmp    f

whereas if I use the struct definition on the line above:
    movl    %edi, %eax
    subq    $8, %rsp
    .cfi_def_cfa_offset 16
    movl    %esi, %edi
    movl    %eax, %esi
    call    f
    addq    $8, %rsp
    .cfi_def_cfa_offset 8
    ret

Somehow gcc doesn't realize that the 2 codes are equivalent (at least that's
how I understand the ABI).

[Bug middle-end/50384] Returning std::array is not optimal

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-28
          Component|other                       |middle-end
            Summary|Copying a char array        |Returning std::array is not
                   |                            |optimal
     Ever Confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-28 19:34:40 UTC ---
(In reply to comment #1)
> Don't know if it is the same problem, but gcc seems to have trouble optimizing
> with structs:

The issue with comment #1 is simple, f is not being marked as a tail call.
The issue with comment #2 is harder, the expanding of the function call is a
bit bogus so is the return.

[Bug middle-end/50384] Returning std::array is not optimal

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384

--- Comment #3 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-28 20:17:20 UTC ---
(In reply to comment #2)
> The issue with comment #1 is simple, f is not being marked as a tail call.

Marking it as a tail call would indeed work for that case. In this slight
variation however, I get a similar long copying to move the return value to an
argument for the next call, where I would expect the compiler to just move the
64bit register that contains it.

#include <array>
typedef std::array<char,7> X;
void h(X);
X f(X,X);
void g(X a,X b){h(f(a,b));}

[Bug middle-end/50384] Returning std::array is not optimal

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=90864
           Severity|normal                      |enhancement