This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C PATCH: Don't generate initializers incrementally
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Re: C PATCH: Don't generate initializers incrementally
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Mon, 6 Nov 2000 13:22:03 -0500
- Cc: Mark Mitchell <mark at codesourcery dot com>, rth at cygnus dot com, gcc-patches at gcc dot gnu dot org
- References: <20001027175908C.mitchell@codesourcery.com> <Pine.LNX.4.30.0011041746520.18965-100000@jsm28.trin.cam.ac.uk>
On Sat, Nov 04, 2000 at 06:00:42PM +0000, Joseph S. Myers wrote:
> On Fri, 27 Oct 2000, Mark Mitchell wrote:
>
> > >>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:
> >
> > Richard> It's not that silly. Consider memory usage while
> > Richard> compiling a large xbm bitmap, or similar
> > Richard> machine-generated data structures. Gcc running out of
> > Richard> memory in such cases is why that code was written in the
> > Richard> first place.
> >
> > I see your point.
> >
> > I would think it should take something pretty huge for that to happen
> > on most machines nowadays. Such stuff certainly isn't portable; lots
> > of compilers actually have hard limits on number of elements in an
> > array initializer, etc.
> >
> > We can blow away the DECL_INITIAL after emitting it if not
> > -fsyntax-only -- that means that the cost is only per global object;
> > it doesn't persist through the translation unit.
> >
> > We could also handle the incrementalism better by noticing that we're
> > getting to be building a real big CONSTRUCTOR, and emitting the first
> > part of it at that point, rather than doing this for all structures.
>
> On trying to work out why C99 designated initializers are currently listed
> as broken, I've concluded that it will generally be necessary to keep the
> whole initializer for an object around until it is finished. C99 allows
> an initializer to override previous initializers (with it being
> unspecified whether the side effects in an overridden initializer occur at
> all - see DR#208). GCC doesn't presently allow this - and for now I'll
> document this as an explanation for the "Broken" entry rather than trying
> to fix it - but it means that an array declaration such as
>
> int i[10000000] = { 0, 1, 2, 3, 4, 5, /* ... */
> 9999998, 9999999, [0] = -1 };
>
> is valid C99, and unless your assembler lets you go backwards and override
> previously specified data, the whole array will need to be kept until the
> closing '}'.
If we really need to do this, then I guess we will have to bite the bullet,
either that or after it sees 500 or so initializers (without seeing named
initializer), start writing the bitmaps to a temporary file.
One thing that would help if for every unique constant we only generate one
tree node, and enter it into a hash table. That reduces the multiplier
somewhat.....
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482