[LTO]: PATCH: PR lto/39010: [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c

[Diego Novillo]

On Fri, Jan 30, 2009 at 16:57, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Jan 30, 2009 at 1:51 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On Fri, Jan 30, 2009 at 16:21, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>>> I think we should avoid htab_hash_string to save some memory. OK
>>> to install?
>>
>> Actually, I prefer the previous patch.  It's clearer and easier to
>> maintain than rolling our own duplicate of htab_hash_string.
>>
>
> I checked in the first version.

Thanks.

> I just want to mention that lto is a memory hog. xmalloc an extra byte will add up.

Yes.  I've been doing some testing and we need to work on that.  I
don't want to micro-optimize it too soon, though.  I would rather find
all the hot spots first and work on those.

The timings I've done on some internal applications show that on a
-fwhopr compile, the C++ parser and the LTRANS phase both account for
50% of all the GGC memory allocated, but the actual streaming phases
(cgraph, decl and gimple I/O) only account for ~1% of all GGC memory
allocated.  This is just the estimate of -ftime-report and does not
include other heap allocations, so better measurements are needed.

Thanks.  Diego.