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: Updated patch (was Re: [PATCH 11/11] Make opt_pass and gcc::pipeline be GC-managed)

On 08/05/2013 05:18 AM, David Malcolm wrote:
> So I *think* the most efficient traversal is to do this first (with a
> suitable comment):
>  for (int i = passes_by_id_size ; i > 0; )
>    ::gt_ggc_mx (passes_by_id[--i]);
> That ought to visit all of the passes without triggering recursion
> (unless someone does something weird to the pass structure in a plugin).


> I'm nervous about omitting the traversal for other pointers the class
> has (though I *think* the passes by id array captures it all) so for
> completeness I'd prefer to then to also do it for all of:
>  ::gt_ggc_mx (all_passes);
>  ::gt_ggc_mx (all_small_ipa_passes);
>  ::gt_ggc_mx (all_lowering_passes);
>  ::gt_ggc_mx (all_regular_ipa_passes);
>  ::gt_ggc_mx (all_lto_gen_passes);
>  ::gt_ggc_mx (all_late_ipa_passes);
> #define NEXT_PASS(PASS, NUM) ::gt_ggc_mx (PASS ## _ ## NUM);
> #include "pass-instances.def"
> #undef NEXT_PASS
> Is it standard in handwritten GC code to omit traversals based on this
> higher-level knowledge?  Presumably it warrants a source comment?
> (having spent too much time lately debugging PCH issues I'm nervous
> about trying to optimize this).

It's something that we should think about when doing any kind of GC.
The deep recursion has bitten us before, and lead to the chain_next
and chain_prev annotations for GTY.

> AIUI we could do similar optimizations in the PCH object-noting hook,
> but can't do similar optimizations in the PCH *op* hook, since every
> field needs to reconstructed when reading the data back from disk.



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