This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] fix PR51910, take 2
On 02/08/2012 03:01 AM, Jakub Jelinek wrote:
On Tue, Feb 07, 2012 at 11:41:03PM -1000, Jason Merrill wrote:
Hmm, I wrote up something quite similar on the plane. One
difference is that mine synchronizes .rpo files that start with some
variants chosen and others not. Does this make sense to you?
You mean the maybe_tweak change? Not sure I understand it.
That and some of the changes in scan_linker_output as well.
Anyway, using VEC is probably cleaner than my patch, on the other
side might be more expensive for the common case where most
symbols don't demangle the same like any other symbol,
because then you allocate a VEC (I think 4 pointers) for each of the
hash table entries, i.e. one extra allocation for each.
It looks like a VEC adds two unsigned ints, whereas your patch adds one
pointer; not a big difference.
Anyway, the question is if the increases in object sizes with -frepo
(due to bringing in unused ctor or dtor variants from time to time)
will be acceptable to -frepo users (if there are any).
I suppose we would run into this with classes with virtual bases that
are not themselves derived from; we wouldn't need the base variant in
that case. So this changes from a link-failure regression to, I
suppose, missed-optimization. I'm OK with that.