On Mon, 2010-05-31 at 11:48 -0700, Mark Mitchell wrote:
> Andi Kleen wrote:
>
> Don't get me wrong; I think virtual functions are very useful. The
> "target hooks" and "language hooks" we have are essentially "poor man's"
> virtual functions, and we could naturally (and mechanically) convert
> them to actual virtual functions.
The GGC marking routines are probably also somehow like virtual
functions, even if they are not implemented as function pointers.
What I mean is that today, the following generated function (from
gtype-desc.c in the build tree)
void
gt_pch_nx_eh_region_d (void *x_p)
{
struct eh_region_d * const x = (struct eh_region_d *)x_p;
if (gt_pch_note_object (x, x, gt_pch_p_11eh_region_d,
gt_ggc_e_11eh_region_d))
{
gt_pch_n_11eh_region_d ((*x).outer);
gt_pch_n_11eh_region_d ((*x).inner);
gt_pch_n_11eh_region_d ((*x).next_peer);
switch ((*x).type)
{
case ERT_TRY:
gt_pch_n_10eh_catch_d ((*x).u.eh_try.first_catch);
gt_pch_n_10eh_catch_d ((*x).u.eh_try.last_catch);
break;
case ERT_ALLOWED_EXCEPTIONS:
gt_pch_n_9tree_node ((*x).u.allowed.type_list);
gt_pch_n_9tree_node ((*x).u.allowed.label);
break;
case ERT_MUST_NOT_THROW:
gt_pch_n_9tree_node ((*x).u.must_not_throw.failure_decl);
break;
default:
break;
}
gt_pch_n_16eh_landing_pad_d ((*x).landing_pads);
gt_pch_n_7rtx_def ((*x).exc_ptr_reg);
gt_pch_n_7rtx_def ((*x).filter_reg);
}
}
could probably be replaced by a virtual function to mark each
eh_region_d, and have 3 subclasses of these for the ERT_TRY,
ERT_ALLOWED_EXCEPTIONS, ERT_MUST_NOT_THROW cases.
I would believe that replacing a complex function like above (which
contains a switch) with a virtual function call could probably be a win
in performance, not a loose.
But perhaps my intuition is wrong. Honestly, I don't have exact figures
of the cost of virtual calls. IIRC, they have been costly for Intel
processors more than 5 years ago (but AMD processors perhaps run them
quicker at that time), but current Intel & AMD processors probably deal
better with indirect jump, so a virtual call is perhaps a with w.r.t. a
complex switch like above.
Another point where virtual functions will greatly help is for dump code
used when debugging GCC & passing some -fdump-... option to GCC.
Besides, in that case, the speed of the dump does not matter much.
Still, my concerns on C++ is mostly gengtype related. I believe we need
to keep a garbage collector even with C++, and I believe that changing
gengtype to follow C++ could be quite painful if we follow the usual
route of parsing our headers. Making a gengtype able to parse almost any
C++ header file would be painful.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
