This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: [PATCH] Fix may_alias canonical types regression


On Mon, Oct 6, 2008 at 12:26 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> This seems sensible.  However, I think it would be useful to measure the
> memory footprint of GCC with this change on some big C++ code.
> (libstdc++ or Boost++ or some such).  DECLs are big, and if we have a
> whole lot more of them, we might be unhappy, and want to look for
> another way to solve this.  So, would you please measure and report?

It's _TYPE nodes we'd be duplicating with this. I did a quick check
with a reasonably large testcase from the Boost Graph Library (194k
lines of preprocessed code, lots of system headers, templates,
template instantiations, etc.). I attached the detailed -fmem-report
statistics, but the bottom line didn't change: we're not using any
more memory. Apparently we're not really sending duplicates through
type_hash_canon. It makes sense that many duplicates don't go that
way: we explicitly duplicate nodes when we see typedefs, and for many
types we have different ways of eliminating duplicate nodes
(TYPE_POINTER_TO, TYPE_REFERENCE_TO, etc.). In places where the C++
front end was mistakenly allowing int and wchar_t to be the same, we
will see some (necessary) duplication, of course.

If someone is set up to easily do memory tests on a larger code base,
I'd love to hear more reports about memory utilization. However, I'm
just not set up to do good memory-utilization testing.

 - Doug

Attachment: mem-performance-canon-before.txt.gz
Description: GNU Zip compressed data

Attachment: mem-performance-canon-after.txt.gz
Description: GNU Zip compressed data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]