This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 6/6] Add manual GTY hooks
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Diego Novillo <dnovillo at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 31 Aug 2013 10:25:52 -0400
- Subject: Re: [PATCH 6/6] Add manual GTY hooks
- Authentication-results: sourceware.org; auth=none
- References: <1377793216-22549-1-git-send-email-dmalcolm at redhat dot com> <1377793216-22549-7-git-send-email-dmalcolm at redhat dot com> <CABu31nPs5DtADbJ1eVZHCPYpB0yTqfejiPJG+WkFaU6VR-zY6g at mail dot gmail dot com> <CAFiYyc1GqbP8mrOENGTSzxM51u4n2TAzCJpf_fP+dk2PD=Vnww at mail dot gmail dot com>
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