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: 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).

Reasonable.

> 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 INSERT_PASSES_AFTER(PASS)
> #define PUSH_INSERT_PASSES_WITHIN(PASS)
> #define POP_INSERT_PASSES()
> #define NEXT_PASS(PASS, NUM) ::gt_ggc_mx (PASS ## _ ## NUM);
> #define TERMINATE_PASS_LIST()
> 
> #include "pass-instances.def"
> 
> #undef INSERT_PASSES_AFTER
> #undef PUSH_INSERT_PASSES_WITHIN
> #undef POP_INSERT_PASSES
> #undef NEXT_PASS
> #undef TERMINATE_PASS_LIST
> 
> 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.

Correct.


r~


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