This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 6/6] Add manual GTY hooks


On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
> On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> > On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm <dmalcolm@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)
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]