public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero   7116 ... memcpy()" with gcc-4.0.2
@ 2005-08-24 13:38 Etienne Lorrain
  2005-08-26  0:01 ` James E Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Etienne Lorrain @ 2005-08-24 13:38 UTC (permalink / raw)
  To: gcc

 Hello,

  Investigated again a big increase of size going from GCC-3.4 to 4.x
 (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
 to reproduce:

  Download and untar gujin, then build "fs.s" :
url_get http://prdownloads.sourceforge.net/gujin/gujin-1.2.tar.gz?download
tar -xvzf gujin-1.2.tar.gz
cd gujin
make dep fs.s CC=/home/etienne/projet/toolchain/bin/gcc

  Then edit fs.s and search the header of function "system_file_load":

        .section        .rodata
        .type   C.171.8759, @object
        .size   C.171.8759, 7116
C.171.8759:
        .zero   7116
        .section        .xcode.system_file_load,"ax",@progbits
        .p2align 1,,1
.globl system_file_load
        .type   system_file_load, @function
system_file_load:
        pushl   %ebp    #
        pushl   %edi    #
        pushl   %esi    #
        pushl   %ebx    #
        subl    $7488, %esp     #, saved_stack.113
        movl    $0, 24(%esp)    #, ax
        movl    $0, 20(%esp)    #, ax
        movl    $0, 16(%esp)    #, ax
        movl    $0, 12(%esp)    #, ax
        movl    $0, 8(%esp)     #, ax
#APP
         bound %esp,STATE+48    # STATE.stack_limit
#NO_APP
        leal    44(%esp), %edi  #, tmp94
        movl    $C.171.8759, %esi       #, tmp95
        cld
        movl    $1779, %ecx     #, tmp96
        rep
        movsl

  That is the result of compiling (INIT is an enum of value 0):

unsigned system_file_load (struct desc_str *elem)
  {bound_stack();{
  z_stream gzlib = { .mode = INIT }; /* everything is null */
  unsigned returned;

  Thanks,
  Etienne.


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2
  2005-08-24 13:38 ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2 Etienne Lorrain
@ 2005-08-26  0:01 ` James E Wilson
  2005-08-26 10:48   ` Etienne Lorrain
  0 siblings, 1 reply; 4+ messages in thread
From: James E Wilson @ 2005-08-26  0:01 UTC (permalink / raw)
  To: Etienne Lorrain; +Cc: gcc

Etienne Lorrain wrote:
>   Investigated again a big increase of size going from GCC-3.4 to 4.x
>  (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
>  to reproduce:

If you want this fixed, you should file a bug report into our bugzilla
database.

Here is a quicker way to reproduce the problem.
int
sub (int i)
{
  int array[1000000] = { 0 };

  sub2 (&array[i]);
}

We are dumping the constructor to memory, and then doing a memcpy, when
it would be much better to just do a memset.

The culprit is code in expand_expr_real_1, case CONSTRUCTOR, which
checks to see if we have a constructor of all constants, in which case
we force it to the constant pool.  Not a good idea if the constructor is
a megabyte in size, and all of the elements are constant zero.  I don't
have a handy gcc-3.4.3 build tree, but it is apparently a VECTOR_TYPE
check that prevents this code from triggering there.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero   7116 ... memcpy()" with gcc-4.0.2
  2005-08-26  0:01 ` James E Wilson
@ 2005-08-26 10:48   ` Etienne Lorrain
  2005-08-26 20:12     ` James E Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Etienne Lorrain @ 2005-08-26 10:48 UTC (permalink / raw)
  To: James E Wilson; +Cc: gcc

  Thanks James,

  Shall I create a new bug report or re-open:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478

  Etienne.

--- James E Wilson <wilson@specifix.com> wrote:
> Etienne Lorrain wrote:
> >   Investigated again a big increase of size going from GCC-3.4 to 4.x
> >  (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
> >  to reproduce:
> 
> If you want this fixed, you should file a bug report into our bugzilla
> database.
> 
> Here is a quicker way to reproduce the problem.
> int
> sub (int i)
> {
>   int array[1000000] = { 0 };
> 
>   sub2 (&array[i]);
> }
> 
> We are dumping the constructor to memory, and then doing a memcpy, when
> it would be much better to just do a memset.
> 
> The culprit is code in expand_expr_real_1, case CONSTRUCTOR, which
> checks to see if we have a constructor of all constants, in which case
> we force it to the constant pool.  Not a good idea if the constructor is
> a megabyte in size, and all of the elements are constant zero.  I don't
> have a handy gcc-3.4.3 build tree, but it is apparently a VECTOR_TYPE
> check that prevents this code from triggering there.
> -- 
> Jim Wilson, GNU Tools Support, http://www.specifix.com
> 



	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero   7116 ... memcpy()" with gcc-4.0.2
  2005-08-26 10:48   ` Etienne Lorrain
@ 2005-08-26 20:12     ` James E Wilson
  0 siblings, 0 replies; 4+ messages in thread
From: James E Wilson @ 2005-08-26 20:12 UTC (permalink / raw)
  To: Etienne Lorrain; +Cc: gcc

On Fri, 2005-08-26 at 01:46, Etienne Lorrain wrote:
>   Shall I create a new bug report or re-open:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478

That's a different bug, in the gimplifier.  This one is in the
middle-end in expand_expr.  I'd suggest opening a new bug as this is a
different problem.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-08-26 18:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-24 13:38 ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2 Etienne Lorrain
2005-08-26  0:01 ` James E Wilson
2005-08-26 10:48   ` Etienne Lorrain
2005-08-26 20:12     ` James E Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).