This is the mail archive of the 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 11/11] Make opt_pass and gcc::pipeline be GC-managed

On Thu, 2013-08-01 at 11:45 -1000, Richard Henderson wrote:
> On 07/26/2013 05:04 AM, David Malcolm wrote:
> > 	(opt_pass::gt_ggc_mx): New.
> > 	(opt_pass::gt_pch_nx): New.
> > 	(opt_pass::gt_pch_nx_with_op): New.
> > 	(gt_ggc_mx (opt_pass *)): New.
> > 	(gt_pch_nx (opt_pass *)): New.
> > 	(gt_pch_nx_opt_pass): New.
> > 	(pipeline::operator new): New.
> > 	(pipeline::gt_ggc_mx): New.
> > 	(pipeline::gt_pch_nx): New.
> > 	(pipeline::gt_pch_nx_with_op): New.
> > 	(gt_ggc_mx (pipeline *)): New.
> > 	(gt_pch_nx (pipeline *)): New.
> > 	(gt_pch_nx_pipeline): New.
> I guess my previous comments about ::gt_ggc_mx vs class::gt_ggc_mx wrt
> the context structure apply as well to this patch.

For context.h, the global functions are used by autogenerated code in
gtype-desc.c, which calls them the first time the context is visited in
a gc or pch traversal; they merely call into the class, to avoid needing
friend decls.

For opt_pass and pass_manager, something different is going on.

For some reason gengtype doesn't generate the triad of gt_ggc_mx_FOO,
gt_pch_nx_FOO, gt_pch_p_NFOO functions in gtype-desc.c, for types
FOO=opt_pass and pass_manager.  Presumably this is because the types are
only visited by code in context.c

So the global functions for opt_pass and pass_manager are a hand-written
implementation of what gengtype would write; they are called *each time*
the entity is reached during a traversal.  The member functions are
called only the *first time* the entity is visited.

Does this need a descriptive comment in the source code?


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