[Bug middle-end/60737] New: rs6000 expand_block_clear uses word stores on double word pointer

[Bug middle-end/60737] New: rs6000 expand_block_clear uses word stores on double word pointer

[anton at samba dot org]

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

            Bug ID: 60737
           Summary: rs6000 expand_block_clear uses word stores on double
                    word pointer
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anton at samba dot org

The following code:

#include <string.h>

void foo(long *p)
{   
    memset(p, 0, 16);
}

When built with a 64bit target:

gcc -mcpu=power8 -O2 -S foo.c

Ends up using 32 byte stores:

foo:
    li 9,0
    stw 9,0(3)
    stw 9,4(3)
    stw 9,8(3)
    stw 9,12(3)
    blr

expand_block_move has a similar issue

[Bug middle-end/60737] rs6000 expand_block_clear uses word stores on double word pointer

[anton at samba dot org]

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

--- Comment #1 from Anton Blanchard <anton at samba dot org> ---
It looks like by the time we get to expand_block_clear we don't have any
alignment info (align_rtx == 1).

[Bug middle-end/60737] rs6000 expand_block_clear uses word stores on double word pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
there isn't any alignment info.

*** This bug has been marked as a duplicate of bug 50417 ***

[Bug target/60737] rs6000 expand_block_clear uses word stores on double word pointer

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
            Version|4.8.3                       |4.10.0
   Last reconfirmed|                            |2014-05-01
          Component|middle-end                  |target
                 CC|                            |amodra at gmail dot com
           Assignee|unassigned at gcc dot gnu.org      |amodra at gmail dot com
         Resolution|DUPLICATE                   |---
     Ever confirmed|0                           |1

--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Reassigning as one aspect of this bug is target specific.  If -mno-strict-align
we should be using 64-bit stores regardless of the alignment info.  What
matters for 64-bit ld/std instructions is that when using reg+offset addressing
that the offset be a multiple of 4.

[Bug target/60737] rs6000 expand_block_clear uses word stores on double word pointer

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra <amodra at gcc dot gnu.org> ---
Author: amodra
Date: Thu May  8 02:05:19 2014
New Revision: 210201

URL: http://gcc.gnu.org/viewcvs?rev=210201&root=gcc&view=rev
Log:
    PR target/60737
    * config/rs6000/rs6000.c (expand_block_move): Allow 64-bit
    loads and stores when -mno-strict-align at any alignment.
    (expand_block_clear): Similarly.  Also correct calculation of
    instruction count.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

[Bug target/60737] rs6000 expand_block_clear uses word stores on double word pointer

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.10.0

--- Comment #5 from Alan Modra <amodra at gmail dot com> ---
Patch applied mainline.