On Fri, 2013-08-30 at 10:40 +0200, Richard Biener wrote:
> On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm <[email protected]> wrote:
> > * gimple.c (gt_ggc_mx (gimple)): New, as required by GTY((user)).
> > (gt_pch_nx (gimple)): Likewise.
> > (gt_pch_nx (gimple, gt_pointer_operator, void *)): Likewise.
> > * gimple.h (gt_ggc_mx (gimple)): Declare.
> > (gt_pch_nx (gimple)): Declare.
> > (gt_pch_nx (gimple, gt_pointer_operator, void *)): Declare.
> > * tree-cfg.c (ggc_mx (gimple&)): Remove declaration, as this
> > collides with the function that GTY((user)) expects.
> > (gt_ggc_mx (edge_def *)): Replace call to gt_ggc_mx on the
> > gimple with gt_ggc_mx_gimple_statement_base: in the
> > pre-GTY((user)) world, "gt_ggc_mx" was the function to be called
> > on a possibly NULL pointed to check if needed marking and if so
> > to traverse its fields. In the GTY((user)) world, "gt_ggc_mx"
> > is the function to be called on non-NULL objects immediately *after*
> > they have been marked: it does not mark the object itself.
> > (gt_pch_nx (gimple&)): Remove declaration.
> > (gt_pch_nx (edge_def *)): Update as per the mx hook.
>
> Btw, this shows that gimple isn't a true C++ hierarchy - because of GTY
> you can only ever use 'gimple' pointers, not more specialized ones
> like gimple_phi as you are missing the GTY machinery for them.
One can definitely use pointers to subclasses on the *stack*, indeed,
the patches use this throughout; IMHO it's an improvement.
FWIW I did a quick test and was also able to add dummy bss subclass ptrs
e.g.:
static GTY(()) gimple_statement_phi *dummy_phi;
This leads to gengtype creating code like this in gtype-desc.c:
void
gt_ggc_mx_gimple_statement_phi (void *x_p)
{
gimple_statement_phi * const x = (gimple_statement_phi *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_mx (x);
}
}
Note how the "gt_ggc_mx (x);" is resolved by using the base-class
implementation of gt_ggc_mx i.e.: gt_ggc_mx (gimple )
since a gimple_statement_phi * is-a gimple_statement_base *.
Anything more complicated than that (e.g. containers) and we're hitting
up against the limitations of gengtype, I guess.
> I'm not 100% convinced that we should do all this at this point without
> getting a better hand on the gengtype issues (it's partial transition to
> the C++ world of GCC)
[...]
