Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers

[Ilya Enkovich <enkovich.gnu@gmail.com>]

2015-03-25 12:50 GMT+03:00 Jakub Jelinek <jakub@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