On Sat, 2013-08-31 at 19:27 +0200, Richard Biener wrote:
> 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?
An update: I've been trying this, but I'm running into what may be a
blocker: types need to be visible in the declaration of the marker
function. Doing this in gtype-desc.h runs into a tangle of dependency
issues. For example:
./gtype-desc.h:2842:28: error: ‘ivarref_entry’ was not declared in this scope
extern void gt_ggc_mx (vec<ivarref_entry,va_gc> *p);
^
In the extreme case, the underlying types in question might be only
declared in one specific .c file. In other cases, there's likely to be
some set of header files needed to get at the types. Also, vec.h uses
ggc.h, which uses gtype-desc.h, and so we have a loop...
AIUI, the mangled names of types in the function names are doing the job
of hiding all the types in gtype-desc.h, so that they are only needed in
the various gt-*.h files and in gtype-desc.c. By changing things so
that the marker function declarations refer to the types directly, all
types need to be known to users of such functions. I'm not sure that
that's possible - or, at least, not if the declarations are in a shared
header file.
Perhaps it could work with some scheme in which the types are
partitioned by .h/.c file, and copies of forward declarations are added
only as-needed to the appropriate gt-*.h/gtype-desc.c files?
I'm trying this now.
BTW, what is the etymology of "gt_ggc_mx" and "gt_pch_nx", and how do
people pronounce them? (I call them the "object-marking" and
"object-noting" hooks" fwiw). As far as I can see, the "m" and and the
"n" come from "mark" and "note"; it's not clear to me where the trailing
"x" came from.
Dave
