[Bug middle-end/29215] Unnecessary use of stack space

[Bug middle-end/29215] Unnecessary use of stack space

[joerg at netbsd dot org]

------- Comment #1 from joerg at netbsd dot org  2006-09-25 14:46 -------
Created an attachment (id=12322)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12322&action=view)
C source to compile with -O2


-- 


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

[Bug middle-end/29215] New: Unnecessary use of stack space

[joerg at netbsd dot org]

The attached file and the output of gcc -O2 -S illustrate the problem.
The inlining of logarg seems to have resulted in a second buffer, which is only
ever written to.


-- 
           Summary: Unnecessary use of stack space
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: joerg at netbsd dot org
  GCC host triplet: i386--netbsdelf


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

[Bug middle-end/29215] Unnecessary use of stack space

[joerg at netbsd dot org]

------- Comment #2 from joerg at netbsd dot org  2006-09-25 14:46 -------
Created an attachment (id=12323)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12323&action=view)
Assembly output


-- 


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

[Bug middle-end/29215] Unnecessary use of stack space

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-25 16:37 -------
First not you are violating C aliasing rules:
*(int *)"abcd"


-- 


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

[Bug middle-end/29215] Unnecessary use of stack space

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-25 16:43 -------
Second this is just a memcpy issue, short testcase:
#include <string.h>

char buf[21];

int main(void)
{
        int a = 0xffffffff;
        memcpy(buf, &a, 4);
        buf[4] = '\0';
        puts(buf);
        return 0;
}


-- 


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

[Bug middle-end/29215] Unnecessary use of stack space

[joerg at netbsd dot org]

------- Comment #5 from joerg at netbsd dot org  2006-09-25 16:48 -------
It is not violating aliasing rules (since a character string can alias with
everything, 6.5p7) nor does it affect this problem.


-- 


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

[Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-25 16:53 -------
Confirmed, Note I think this should wait until 4.3.0 to be fixed on the tree
level.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|i386--netbsdelf             |
           Keywords|                            |missed-optimization
      Known to fail|                            |4.0.0 4.1.0 4.2.0
      Known to work|                            |3.4.0
   Last reconfirmed|0000-00-00 00:00:00         |2006-09-25 16:53:19
               date|                            |
            Summary|Unnecessary use of stack    |[4.0/4.1/4.2 Regression]
                   |space                       |memcpy is not fully
                   |                            |optimized any more
   Target Milestone|---                         |4.0.4


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

[Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-09-25 16:55 -------
(In reply to comment #5)
> It is not violating aliasing rules (since a character string can alias with
> everything, 6.5p7) nor does it affect this problem.
No you are reading it the wrong way; accessing via the character type is valid
and the orginal type (which this case is the character type).  C aliasing rules
are not transative.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-09-25 16:53:19         |2006-09-25 16:55:18
               date|                            |
   Target Milestone|4.0.4                       |---


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

[Bug middle-end/29215] Unnecessary use of stack space

[joerg at netbsd dot org]

------- Comment #8 from joerg at netbsd dot org  2006-09-25 16:57 -------
> Second this is just a memcpy issue, short testcase:
> #include <string.h>
> 
> char buf[21];
> 
> int main(void)
> {
>         int a = 0xffffffff;
>         memcpy(buf, &a, 4);

This creates two movl, one for a and one to buf. When duplicating the memcpy
multiples times, it stays one for a and one for each memcpy.

Manually inline the original testcase shows the same behaviour.

I think the real problem is in this example a is written to the stack and not
optimised away. For the original test case the lazy stack cleanup would explain
the multiple assignments.


-- 

joerg at netbsd dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|                            |i386--netbsdelf
           Keywords|missed-optimization         |
      Known to fail|4.0.0 4.1.0 4.2.0           |
      Known to work|3.4.0                       |
            Summary|[4.0/4.1/4.2 Regression]    |Unnecessary use of stack
                   |memcpy is not fully         |space
                   |optimized any more          |


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

[Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-09-25 17:03 -------
(In reply to comment #8)
> I think the real problem is in this example a is written to the stack and not
> optimised away. For the original test case the lazy stack cleanup would explain
> the multiple assignments.

You are partly correct.  What is happening is that we don't optimize memcpy at
the tree level.  So we expand to have a always in a stack slot and then we
optimize the memcpy at the rtl level (by inlining it) and the later passes are
there to do constant prop but we don't rememove the store to a even though it
is dead.  3.4.0 and before used to do this via the addressof rtl which fixed
the problem by not committing a into the stack until later.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
      Known to fail|                            |4.0.0 4.1.0 4.2.0
      Known to work|                            |3.4.0
            Summary|Unnecessary use of stack    |[4.0/4.1/4.2 Regression]
                   |space                       |memcpy is not fully
                   |                            |optimized any more
   Target Milestone|---                         |4.0.4


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

[Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] memcpy is not fully optimized any more

[gdr at gcc dot gnu dot org]

------- Comment #10 from gdr at gcc dot gnu dot org  2007-02-03 20:24 -------
won't fix in GCC-4.0.x.  Adjusting milestone.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.4                       |4.1.3


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] memcpy is not fully optimized any more

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.3                       |4.1.2


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] memcpy is not fully optimized any more

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] memcpy is not fully optimized any more

[steven at gcc dot gnu dot org]

------- Comment #11 from steven at gcc dot gnu dot org  2007-12-16 23:18 -------
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] extra store for memcpy

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2007-12-16 23:55 -------
These are just extra stores.  This looks exactly like PR 30271.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |30271
   GCC host triplet|i386--netbsdelf             |
 GCC target triplet|                            |i386--netbsdelf
      Known to work|3.4.0                       |3.4.0 4.3.0
            Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2/4.3 Regression]
                   |memcpy is not fully         |extra store for memcpy
                   |optimized any more          |


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] extra store for memcpy

[ubizjak at gmail dot com]

------- Comment #13 from ubizjak at gmail dot com  2008-01-25 18:36 -------
A 4.3 Regression that is known to work on 4.3.0?

Could someone please fix this inconsistency.


-- 


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

[Bug middle-end/29215] [4.2/4.3/4.4 Regression] extra store for memcpy

[jsm28 at gcc dot gnu dot org]

------- Comment #14 from jsm28 at gcc dot gnu dot org  2008-07-04 21:31 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
                   |extra store for memcpy      |extra store for memcpy
   Target Milestone|4.1.3                       |4.2.5


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

[Bug middle-end/29215] [4.2/4.3/4.4 Regression] extra store for memcpy

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2008-11-13 15:28 -------
This is a regression from 3.4 still present in 4.3/4.4.
At the tree level, we only fold memcpy if the size of the source and
destination
elements is the same and length is tgat size (say
int i = 6;
float f;
memcpy (&f, &i, sizeof (int));
) into an assignment.  As this isn't the case here, before expansion we have:
main ()
{
  int arg1;
  int arg2;
  int arg3;
  int arg4;
  int arg5;
  int D.1602;

<bb 2>:
  D.1602 = *(int *) "abcd";
  arg1 = D.1602;
  arg2 = D.1602;
  arg3 = D.1602;
  arg4 = D.1602;
  arg5 = D.1602;
  __builtin_memcpy (&buf, &arg1, 4);
  __builtin_memcpy (&buf[4], &arg2, 4);
  __builtin_memcpy (&buf[8], &arg3, 4);
  __builtin_memcpy (&buf[12], &arg4, 4);
  __builtin_memcpy (&buf[16], &arg5, 4);
  buf[20] = 0;
  __builtin_puts (&buf);
  return 0;

}

and all of arg{1,2,3,4,5} are TREE_ADDRESSABLE.  In 3.4 ADDRESSOF took care of
optimizing out these dead stores.  But ADDRESSOF is gone, and RTL DSE is
apparently unable to kill these.  No idea why dse1 doesn't kill it, dse2
doesn't
at least on x86_64 because pro_epilogue_adjust_stack_rex64 has (clobber
(mem:BLK (scratch))) in it.

On the tree level, we could perhaps optimize this by adding special builtins
and transforming __builtin_memcpy into it if possible.  Say have
void *__builtin_memstore2 (char *, HImode);, void *__builtin_memstore4 (char *,
SImode); etc., and transform say
__builtin_memcpy (buffer + 8, &arg2, sizeof (arg2)) into
__builtin_memstore4 (buffer + 8, arg2); (or for non-integral types, say arg2
being float, __builtin_memstore4 (buffer + 8, VCE<SImode, arg2>).  At expansion
time these builtins would check if the second argument must live in memory.
If yes, it would just expand it as __builtin_memcpy.  Otherwise it would just
do a store (with alias set 0).  Or we could try to play with
TYPE_REF_CAN_ALIAS_ALL pointers.

That said, it would be good to know why DSE doesn't eliminate these dead
stores.


-- 


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

[Bug middle-end/29215] [4.2/4.3/4.4 Regression] extra store for memcpy

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2008-11-14 10:50 -------
Testing a patch with TYPE_REF_CAN_ALIAS_REF pointers.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-01-15 20:18:17         |2008-11-14 10:50:43
               date|                            |


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

[Bug middle-end/29215] [4.2/4.3/4.4 Regression] extra store for memcpy

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2008-11-20 21:36 -------
Subject: Bug 29215

Author: jakub
Date: Thu Nov 20 21:35:03 2008
New Revision: 142061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142061
Log:
        PR middle-end/29215
        * builtins.c (SLOW_UNALIGNED_ACCESS): Define if not defined.
        (fold_builtin_memory_op): Handle even the case where just one
        of src and dest is an address of a var decl component, using
        TYPE_REF_CAN_ALIAS_ALL pointers.  Remove is_gimple_min_invariant
        and readonly_data_expr src check.
        * tree-ssa-sccvn.c (DFS): Use clear_and_done_ssa_iter to shut
        up warnings.

        * trans-array.c (trans_array_constructor_value,
        gfc_build_constant_array_constructor): Fill in TREE_PURPOSE.

        * gfortran.dg/array_memcpy_3.f90: Adjust pattern to match even
        memcpy optimized into ref-all store.
        * gcc.dg/pr29215.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr29215.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/array_memcpy_3.f90
    trunk/gcc/tree-ssa-sccvn.c


-- 


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

[Bug middle-end/29215] [4.2/4.3 Regression] extra store for memcpy

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2008-11-20 21:39 -------
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.0 4.0.4 4.1.0 4.2.0     |4.0.0 4.0.4 4.1.0 4.2.0
                   |                            |4.3.2
      Known to work|3.4.0                       |3.4.0 4.4.0
            Summary|[4.2/4.3/4.4 Regression]    |[4.2/4.3 Regression] extra
                   |extra store for memcpy      |store for memcpy


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

[Bug middle-end/29215] [4.3 Regression] extra store for memcpy

[jsm28 at gcc dot gnu dot org]

------- Comment #19 from jsm28 at gcc dot gnu dot org  2009-03-31 19:44 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3 Regression] extra  |[4.3 Regression] extra store
                   |store for memcpy            |for memcpy
   Target Milestone|4.2.5                       |4.3.4


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

[Bug middle-end/29215] [4.3 Regression] extra store for memcpy

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2009-08-04 12:27 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug middle-end/29215] [4.3 Regression] extra store for memcpy

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-04-20 13:26 -------
WONTFIX on the 4.3 branch.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.0.0 4.0.4 4.1.0 4.2.0     |4.0.0 4.0.4 4.1.0 4.2.0
                   |4.3.2                       |4.3.2 4.3.4
         Resolution|                            |FIXED
   Target Milestone|4.3.5                       |4.4.0


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

[Bug middle-end/29215] [4.3 Regression] extra store for memcpy

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
Bug 29215 depends on bug 30271, which changed state.

Bug 30271 Summary: -mstrict-align can add an store extra for struct argument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED