[Bug rtl-optimization/47582] New: Combine chains of movl into movq

[Bug rtl-optimization/47582] New: Combine chains of movl into movq

[tony.poppleton at gmail dot com]

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

           Summary: Combine chains of movl into movq
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tony.poppleton@gmail.com


The following C code (adapted from
http://stackoverflow.com/questions/4544804/in-what-cases-should-i-use-memcpy-over-standard-operators-in-c)
shows that adjacent sequences of movl could be combined into movq.

extern float a[5];
extern float b[5];

int main()
{
#if defined(M1)
    a[0] = b[0];
    a[1] = b[1];
    a[2] = b[2];
    a[3] = b[3];
    a[4] = b[4];
#elif defined(M2)
    memcpy(a, b, 5*sizeof(float));
 #endif
}

When compiled with "-O2 -fomit-frame-pointer" on GCC 4.3.5, 4.4.5, 4.5.2 and
4.6.0 (20110129), the following asm is produced for the -DM1 branch:
        movl    b(%rip), %eax
        movl    %eax, a(%rip)
        movl    b+4(%rip), %eax
        movl    %eax, a+4(%rip)
        movl    b+8(%rip), %eax
        movl    %eax, a+8(%rip)
        movl    b+12(%rip), %eax
        movl    %eax, a+12(%rip)
        movl    b+16(%rip), %eax
        movl    %eax, a+16(%rip)
        ret

However for the -DM2 branch, the memcpy implementation shows that this can be
done more efficiently:
        movq    b(%rip), %rax
        movq    %rax, a(%rip)
        movq    b+8(%rip), %rax
        movq    %rax, a+8(%rip)
        movl    b+16(%rip), %eax
        movl    %eax, a+16(%rip)
        ret

I presume that the memcpy is being done in hand-written asm?  If so, then once
this enhancment is done, then presumably that portion of memcpy code could be
converted to C code and be just as efficient.

[Bug rtl-optimization/47582] Combine chains of movl into movq

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |23684

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-02-01 22:46:02 UTC ---
Most of the issue is recorded in PR 23684.

[Bug rtl-optimization/47582] Combine chains of movl into movq

[tony.poppleton at gmail dot com]

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

--- Comment #2 from Tony Poppleton <tony.poppleton at gmail dot com> ---
Re-testing this with GCC 5.1, the code appears to be even less efficient, for
both cases;

DM1:
.LFB0:
        .cfi_startproc
        movss   b(%rip), %xmm0
        xorl    %eax, %eax
        movss   %xmm0, a(%rip)
        movss   b+4(%rip), %xmm0
        movss   %xmm0, a+4(%rip)
        movss   b+8(%rip), %xmm0
        movss   %xmm0, a+8(%rip)
        movss   b+12(%rip), %xmm0
        movss   %xmm0, a+12(%rip)
        movss   b+16(%rip), %xmm0
        movss   %xmm0, a+16(%rip)
        ret
        .cfi_endproc

.LFB0:
        .cfi_startproc
        movq    b(%rip), %rax
        movq    %rax, a(%rip)
        movq    b+8(%rip), %rax
        movq    %rax, a+8(%rip)
        movl    b+16(%rip), %eax
        movl    %eax, a+16(%rip)
        xorl    %eax, %eax
        ret
        .cfi_endproc

Why is the "xorl" appearing in both cases?  Should this be logged as a separate
bug.

Incidentally, compiling with -O1 produces the same code as -O2 on older GCCs
(as in the description comment above)

My total guess is it is due to a and b not having any initial values, and an
optimization that takes into account value ranges is getting confused?

[Bug rtl-optimization/47582] Combine chains of movl into movq

[tony.poppleton at gmail dot com]

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

--- Comment #3 from Tony Poppleton <tony.poppleton at gmail dot com> ---
Ignore the last comment - hadn't spotted the "int" return value on main...

So the code is actually more correct than previous versions, and no change to
the status of this bug.