[PATCH] Canonical types (1/3)

Doug Gregor doug.gregor@gmail.com
Tue Nov 28 18:06:00 GMT 2006

On 28 Nov 2006 08:43:00 -0800, Ian Lance Taylor <iant@google.com> wrote:
> Your compile time measurements are impressive.  I am curious, though:
> have you done any measurements of memory usage, e.g., -fmem-report?

Not yet, and unfortunately I'm now disconnected from the machine that
has all of the necessary builds... I'll report back with some memory
usage results.

> 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?

Hmmm, we could do that... it depends on whether you want to view the
newly-created variant as being equivalent to the original type or
being different by default. When the caller wants something different
from the default, they need to tweak TYPE_CANONICAL.

Right now, the default for build_variant_type_copy is to return a type
that is different (has a different canonical type) than the original
type it was given. That's the right thing to do for cv-qualifiers, but
the wrong thing to do for, e.g., typedefs. So, the typedef handling
code patches up TYPE_CANONICAL.

I picked this default because I thought the failure mode when callers
don't patch up TYPE_CANONICAL properly would be better this way.
Having two types share the same canonical type when they should be
different is likely to result in really weird behavior. Having two
different canonical types for otherwise equivalent type nodes is
easier to debug/detect (in my experience). That said, we build many
more kinds of type variants that are equivalent to the original types
than we do type variants that aren't equivalent. So, the patch would
be smaller if we switched the default for build_variant_type_copy. I
don't have much of a preference

Or, we could even push the issue by adding an extra parameter to
build_variant_type_copy. Then callers would fail to compile if they
didn't say what they wanted.

> 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.

I used "-f" partly because all of the good -d's were taken and partly
because we might need to ask users to add -fcheck-canonical-types when
reporting bugs that involve type equality problems.


More information about the Gcc-patches mailing list