This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Duplicated Constants
- To: Brian Shaft <bshaft at cisco dot com>
- Subject: Re: Duplicated Constants
- From: Carlo Wood <carlo at alinoe dot com>
- Date: Sat, 14 Jul 2001 05:14:41 +0200
- Cc: Gcc Gurus <gcc at gcc dot gnu dot org>
- References: <3B4F9D38.D76AD773@cisco.com>
On Fri, Jul 13, 2001 at 06:15:36PM -0700, Brian Shaft wrote:
> "gcc.utils.help" were silent on this. Any interest from the gcc side?
>
> Bfd has infrastructure for re-using constants (e.g. _bfd_stringtab_add) and
> seems to make one copy of a constant for each .o file. However when multiple
> files are linked together, it appears that there is no further optimization. If
> there are lots of files, the final executable often ends up with many copies of
> the same constants.
I sense some "confusion" around the word 'constant', are you sure you don't
mean string-literal? I said this because I think that constants (i.e. a
int const foo = 3; should be optimized away in most case and doesn't need
to appear in the final executable anyway unless one is using a constant
pointer to it (which would be stupid)). Moreover, int's don't use a lot
of memory. So, if you restrict yourself to string literals you might win
most memory back anyway.
However, that is not possible unless there is relocation information available
for the (pointers to) the string-literals - and when that isn't there, there is
nothing ld can do.
For example, if one object file contains:
char const* const hello = "Hello world"; // A constant.
bool foo(char const* s) { return s == hello; }
And another object file contains:
char const* const hello = "Hello world"; // A constant.
bool bar(char const* s) { return foo(hello); }
And you REALLY want these two constants to be equal based on the fact
that they are constant character arrays with the same content,
then the value of `hello' in either the first or the second object
file needs to be changed during linking.
On the other hand, because that would change the behaviour of the application,
I am not sure that this would be conforming to the standard.
> It looks like extending this optimization to ld might buy back some of the
> increases in memory usage with the recent gcc compilers - so we (Cisco) are
> interested in attempting it. Has anybody been down this path before? Any tips,
> warnings, or flames?
>
> Brian Shaft
>
> I have nothing to declare but my identifiers
--
Carlo Wood <carlo@alinoe.com>