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/02/2013 02:48 PM, David Malcolm wrote:
> +pass_manager::gt_ggc_mx ()
> +{
> +  ::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);
> +
> +  for (int i = 0; i < passes_by_id_size; i++)
> +    ::gt_ggc_mx (passes_by_id[i]);
> +
> +#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
> +
> +}

You're marking all passes, and also walking through the chain of sub/next
within the passes themselves?  That seems unnecessary.  Either the passes
are reachable via sub/next or they aren't.

Alternately, don't walk the sub/next fields and instead only walk all of
the passes explicitly, here.  That avoids some of the recursion in the
opt_pass marking, and keeps the call chain flatter.


r~


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