On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
> On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher <[email protected]>
> 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.
> >
> > GIMPLE isn't supposed to end up in a PCH. Can you please make this
> > function simply call gcc_unreachable()?
> >
> > FWIW 1: I really think all these hand-written markers aren't a good
> > idea, we should really figure out a way to have automatic marker
> > function generators, something less complex than gengtype, of course.
> > But to have all these calls to the type-mangled marker functions
> > (gt_pch_n_9tree_node, etc.) is going to be a problem in the long term.
> >
> > It seems to me that the first step in all these conversions to
> > hand-written markers should be to make gengtype spit out the marker
> > functions *without* the type name mangling, i.e. all marker functions
> > should just be gt_ggc_mx(type) / gt_pch_nx(type).
>
> Yes, the original idea was that gengtype would do that. For things we like
> to optimize the GTY((user)) thing would tell it that we do provide the
> markers.
> Like when you want to look through a non-GCed intermediate object. Or
> for things like GTY((chain)) stuff that doesn't really work if you have
> multiple
> chains (without clever GTY((skip))s...).
>
> The lack of the unmangled overloads is annoying :/ IIRC Diego halfway
> completed
> the transition to unmangled overloads / specializations?
How would that work, and is that something that it would be productive
for me to work on?
Currently AIUI gtype-desc.h contains mangled macros and decls e.g.:
extern void gt_ggc_mx_rtvec_def (void *);
#define gt_ggc_m_9rtvec_def(X) do { \
if (X != NULL) gt_ggc_mx_rtvec_def (X);\
} while (0)
and the corresponding functions in gtype-desc.c contain:
void
gt_ggc_mx_rtvec_def (void *x_p)
{
struct rtvec_def * const x = (struct rtvec_def *)x_p;
if (ggc_test_and_set_mark (x))
{
/* visit fields of x, invoking the macros */
}
}
Is the goal for the field-visiting code to all be able to simply do:
gt_ggc_mx (field)
and have overloading resolve it all? (and handle e.g. chain_next etc
etc)
Presumably if this were implemented, then hand-written GTY functions
would be that much easier to maintain, and perhaps this gimple
conversion idea would be more acceptable? (or, in other words, should I
work on this?)
Thanks
Dave
