2015-03-25 12:50 GMT+03:00 Jakub Jelinek <ja...@redhat.com>: > On Wed, Mar 25, 2015 at 10:38:56AM +0100, Richard Biener wrote: >> --- gcc/passes.c (revision 221633) >> +++ gcc/passes.c (working copy) >> @@ -156,7 +156,8 @@ void >> pass_manager::execute_early_local_passes () >> { >> execute_pass_list (cfun, pass_build_ssa_passes_1->sub); >> - execute_pass_list (cfun, pass_chkp_instrumentation_passes_1->sub); >> + if (flag_check_pointer_bounds) >> + execute_pass_list (cfun, pass_chkp_instrumentation_passes_1->sub); >> execute_pass_list (cfun, pass_local_optimization_passes_1->sub); >> } >> >> @@ -424,7 +425,8 @@ public: >> virtual bool gate (function *) >> { >> /* Don't bother doing anything if the program has errors. */ >> - return (!seen_error () && !in_lto_p); >> + return (flag_check_pointer_bounds >> + && !seen_error () && !in_lto_p); >> } >> >> }; // class pass_chkp_instrumentation_passes > > There is still the wasteful pass_fixup_cfg at the start of: > PUSH_INSERT_PASSES_WITHIN (pass_local_optimization_passes) > NEXT_PASS (pass_fixup_cfg); > which wasn't there before chkp. Perhaps this should be a different > pass with the same execute method, but gate containing > flag_check_pointer_bounds?
IIRC the reason for this pass was a different passes split, not instrumentation itself. Previously function processing always started with pass_fixup_cfg. Splitting processing into three stages we got three pass_fixup_cfg passes. Ilya > > Jakub