This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Canonical types (1/3)
- From: Ian Lance Taylor <iant at google dot com>
- To: "Doug Gregor" <doug dot gregor at gmail dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>
- Date: 28 Nov 2006 08:43:00 -0800
- Subject: Re: [PATCH] Canonical types (1/3)
- References: <firstname.lastname@example.org>
[ Dropping gcc@, this is appropriate for gcc-patches@ ]
"Doug Gregor" <email@example.com> writes:
> This patch introduces canonical types into GCC, which allow us to
> compare two types very efficiently and results in an overall
> compile-time performance improvement. I have been seeing 3-5%
> improvements in compile time on the G++ and libstdc++ test suites,
> 5-10% on template-heavy (but realistic) code in Boost, and up to 85%
> improvement for extremely template-heavy metaprogramming.
Thanks for doing this work!
Your compile time measurements are impressive. I am curious, though:
have you done any measurements of memory usage, e.g., -fmem-report?
When I look at the patch that you have changed various calls to
build_variant_type_copy to then set TYPE_CANONICAL. Why not simply
set TYPE_CANONICAL in build_variant_type_copy?
> There is some danger in introducing canonical types: if we fail to
> canonicalize properly, types won't compare equal when they should, and
> we'll break code. To mitigate this problem, I have added a flags
> -f(no-)check-canonical-types. When enabled, GCC will check the
> canonical types against the structural types; where they differ, it
> will print a warning and use the structural information. When
> disabled, we only use canonical types... and get better compile-time
> performance. Canonical type checking is disabled by default for normal
> builds, enabled by default when --enable-checking is present. Note,
> however, that this flag is temporary: after a major release or two,
> when we're sure that we have our canonical type system, we can
> eliminate it.
This is a very minor point, but I wonder if this flag should have a
different name. As far as I know we don't currently have any -f flags
which are strictly for compiler developers. We usually put those in
-d or --param.