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: [C++ PATCH] Compare binfo types directly


Nathan Sidwell wrote:

Mark,
this patch replaces 'same_type_p (BINFO_TYPE (b), t)' with
'BINFO_TYPE (b) == t'. I know you've expressed reservations about omitting
same_type_p calls in this way, so I'm running this by you for comment
before committing.

I guess the big question I have is not "does this work at the moment?" but "should it always work in the future?"


For example, if the user writes:

 struct A {};
 typedef A T;
 struct B : public T {};

should the BINFO for A-in-B actually be for T-in-B? In general, we've tried to preserve the type that the user used for better error messages, potentially better debug messages, and (ikn the distant future) better behavior when using the G++ front end independent of the GCC back end.

Another way to target that 0.5% improvement (and perhaps get an even bigger one) would be to try to reduce the number of base class walks, etc. that we do. (For example, create virtual table initializers lazily when needed, rather than generating their initializers in finish_struct_1, and then fiddling with DECL_EXTERNAL to prevent them from being emitted.) I suspect we could also do fewer searches when looking up identifiers, etc.

However, I can't really justify not grabbing an easy half percent.

How about this: define a new SAME_BINFO_TYPE_P macro which does the "==" test, and use it. Put a comment on it that reflects some of this discussion, and indicates that we might at some point switch it to use same_type_p. That makes it easy for us to move to the "T" choice above, but still gets us the win now.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com


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