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


Jason


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