[Bug target/60879] New: Wrong decision in decide_alg

[Bug target/60879] New: Wrong decision in decide_alg

[hjl.tools at gmail dot com]

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

            Bug ID: 60879
           Summary: Wrong decision in decide_alg
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: ubizjak at gmail dot com

decide_alg has

  /* Very tiny blocks are best handled via the loop, REP is expensive to
     setup.  */
  else if (expected_size != -1 && expected_size < 4)
    return loop_1_byte;

We use 1-byte loop on fixed size 1, 2 and 3.  We should simply unroll
loop.

[Bug target/60879] Wrong decision in decide_alg in i386.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does this ever matter though?  I mean, wouldn't we expand it as move by pieces
or store by pieces for such small constant length anyway and thus never reach
the target movmem/setmem expansion?

[Bug target/60879] Wrong decision in decide_alg in i386.c

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Does this ever matter though?  I mean, wouldn't we expand it as move by
> pieces or store by pieces for such small constant length anyway and thus
> never reach the target movmem/setmem expansion?

move by pieces or store by pieces are very efficient for
targets with unaligned move/store for integer and vector:

[hjl@gnu-6 partial]$ cat w.i
void
foo5 (const void *src, void *dest, int s)
{
  __builtin_memcpy (dest, src, 23);
}
[hjl@gnu-6 partial]$ gcc -S -O2 w.i
[hjl@gnu-6 partial]$ cat w.s

    .file    "w.i"
    .text
    .p2align 4,,15
    .globl    foo5
    .type    foo5, @function
foo5:
.LFB0:
    .cfi_startproc
    movq    (%rdi), %rax
    movq    %rax, (%rsi)
    movq    8(%rdi), %rax
    movq    %rax, 8(%rsi)
    movl    16(%rdi), %eax
    movl    %eax, 16(%rsi)
    movzwl    20(%rdi), %eax
    movw    %ax, 20(%rsi)
    movzbl    22(%rdi), %eax
    movb    %al, 22(%rsi)
    ret

I am working on a different set/mov memory strategy to generate

    movdqu    (%rdi), %xmm0
    movups    %xmm0, (%rsi)
    movq    15(%rdi), %rax
    movq    %rax, 15(%rsi)
    ret

by setting MOVE_RATIO to 1 and handling most of set/mov memory in
x86 backend.

[Bug target/60879] Wrong decision in decide_alg in i386.c

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
           Keywords|                            |missed-optimization

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed on the trunk:

        movdqu  (%rdi), %xmm0
        movups  %xmm0, (%rsi)
        movq    15(%rdi), %rax
        movq    %rax, 15(%rsi)
        ret


While GCC 11 produced:

        movdqu  (%rdi), %xmm0
        movups  %xmm0, (%rsi)
        movl    16(%rdi), %eax
        movl    %eax, 16(%rsi)
        movzwl  20(%rdi), %eax
        movw    %ax, 20(%rsi)
        movzbl  22(%rdi), %eax
        movb    %al, 22(%rsi)
        ret