David Malcolm <dmalc...@redhat.com> wrote: >On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote: >> On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher ><stevenb....@gmail.com> wrote: >> > On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm ><dmalc...@redhat.com> 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)
Yes. The advantage is that gengtype this way only needs to parse field names and not types which is a lot easier. >and have overloading resolve it all? (and handle e.g. chain_next etc >etc) Yes. All bits that would require more complex parsing should instead be telled explicit via a GTY annotation. >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?) That would be very nice! IIRC Diego had issues with making all declarations visible to make this work. Diego? Richard. >Thanks >Dave