This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] fix opt/13798
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: rth at atrey dot karlin dot mff dot cuni dot cz, gcc-patches at gcc dot gnu dot org
- Date: Wed, 28 Jan 2004 13:33:47 +0100
- Subject: Re: [tree-ssa] fix opt/13798
- References: <20040128092714.GA32557@redhat.com>
> The problem shown by this case is similar to that addressed recently in
> the C++ front end wrt static initializers. It really really sucks to
> generate 40,000 assignment statements in order to initialize a large array.
> This duplicates some logic that expr.c uses in the tree->rtl converter
> to decide to drop such large constructors into readonly memory. We then
> memcpy from the readonly memory to the variable.
> One change from the expr.c logic is that, if the variable itself is
> marked readonly, then the variable is promoted to be static. This
> eliminates the need for a memcpy at all. I can't find any downside
> to this promotion, so it is done unconditionally, no matter the size
> of the constructor.
> This does highlight a flaw in the cgraph code in that it cannot remove
> unused local static variables. Primarily because it doesn't even see
> these variables until after it has decided all variables must be emitted.
> I'm not sure how to address this, exactly.
I think the proper sollution would be to simply deal with local static
variables as if they were global by frontends, but I didn't get across
to implement this yet.