When using C99 initializers, i.e.: struct bleh *blah = malloc( sizeof *blah ); *blah = (struct bleh){ .field1 = value1, ... }; the code generated is far bigger than the traditional blah->field1 = value1; ... Release: 3.2.1 Environment: x86
State-Changed-From-To: open->feedback State-Changed-Why: Can you send a self-contained code example that shows this? Thanks Wolfgang
From: Marius Bernklev <gcc-bugs@gcc.gnu.org> To: bangerth@dealii.org Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c/9540: C99 initializers generate lots of code Date: Mon, 03 Feb 2003 13:34:19 +0100 bangerth@dealii.org writes: > Synopsis: C99 initializers generate lots of code > > State-Changed-From-To: open->feedback > State-Changed-By: bangerth > State-Changed-When: Sun Feb 2 22:15:57 2003 > State-Changed-Why: > Can you send a self-contained code example that shows this? > > Thanks > Wolfgang > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9540 > Certainly. :) Here goes: // Start of vector.c #include <stdlib.h> // well, I need size_t // imaginary garbage collector allocator extern void *gc_malloc(size_t); struct string { size_t size; size_t length; char *restrict string; int hash; }; struct string *new_vector1( const size_t length ) { struct string *const restrict result = gc_malloc( sizeof *result ); *result = (struct string) { .size = sizeof *result, .length = length, .string = gc_malloc( length ), .hash = -1 }; return result; } struct string *new_vector2( const size_t length ) { struct string *const restrict result = gc_malloc( sizeof *result ); result->size = sizeof *result; result->length = length; result->string = gc_malloc( length ); result->hash = -1; return result; } --------------------------- with gcc 3.2.1 on x86, with the command line gcc -std=c99 -S vector.c, the code generated for new_vector1 is somewhat larger than for new_vector2. Marius -- <URL: http://home.ifi.uio.no/~mariube/ > Life sucks. Death swallows.
State-Changed-From-To: feedback->open State-Changed-Why: Feedback received. The sizes of the two functions are indeed different, but I have too little knowledge of the optimizers to analyze whether they differ in any measurable quantity (run-time, clock-ticks), so leave this to others. W.
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: gcc-prs@gcc.gnu.org, mariube+gcc+@ifi.uio.no, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: optimization/9540: C99 initializers generate lots of code Date: Tue, 13 May 2003 15:17:39 +0200 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9540 The code size of the two functions differs because you do two fundamentally different things: * new_vector1 creates a compound literal (this is a separate object not just an initializer!) of type string. The contents of this object are then assigned to *result. * new_vector2 initializes *result directly without the construction of an intermediate compound literal. The additional instructions that you see are the result of the copying which is in general necessary because we can't know if gc_malloc might rely on the memory in *result or might modify previously initialized elements of the compound literal. The latter might be impossible due to aliasing rules but I'm not entirly sure about this. The former is definitely possible, e.g. if the first call to gc_malloc also stored the return value in some static or global variable. Given the fact that gcc does optimize the mem to mem copy away if the compound literal is declared const and gc_malloc is called outside of the initializer I guess that there aren't enough aliasing restrictions to allow the optimization otherwise. regards Christian -- THAT'S ALL FOLKS!
Confirmed with gcc 3.3 branch and mainline (20030601) on powerpc-darwin, althought it's only 4 instructions longer on that platform... Christian, your last post indicated you thought this was a bug (missed opportunity) with alias optimization, correct? Thanks, Dara
This bug has nothing to do with aliasing but it has to do with GCC creating a temp variable to store the C99 initializer and then copying that into the global variable.
Is another case where GCC puts structs (objects) on the stack to early, setting target to the tree- ssa.
Suspending as it is already fixed on the tre-ssa.
Fixed on the tree-ssa so closing.
Reopening the bugs that are fixed on the tree-ssa (but not reported against the branch).
Suspending based on this is fixed on the tree-ssa.
Fixed for 3.5.0 by the merge of the tree-ssa.