This is the mail archive of the gcc@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: [gimplefe] hacking pass manager


On 8 July 2016 at 13:13, Richard Biener <richard.guenther@gmail.com> wrote:
> On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>> On 6 July 2016 at 14:24, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>>>> On 30 June 2016 at 17:10, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>>> <prasad.ghangal@gmail.com> wrote:
>>>>>> On 29 June 2016 at 22:15, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal <prasad.ghangal@gmail.com>
>>>>>>>>wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I tried hacking pass manager to execute only given passes. For this I
>>>>>>>>> am adding new member as opt_pass *custom_pass_list to the function
>>>>>>>>> structure to store passes need to execute and providing the
>>>>>>>>> custom_pass_list to execute_pass_list() function instead of all
>>>>>>>>passes
>>>>>>>>>
>>>>>>>>> for test case like-
>>>>>>>>>
>>>>>>>>> int a;
>>>>>>>>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>>>>>>>>> {
>>>>>>>>> bb_1:
>>>>>>>>>   a = 1 + a;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>>>>>>>>function
>>>>>>>>>
>>>>>>>>> and for test case like -
>>>>>>>>>
>>>>>>>>> int a;
>>>>>>>>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>>>>>>>>> {
>>>>>>>>> bb_1:
>>>>>>>>>   a = 1 + a;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> it will act as a entry point to the pipeline and will execute passes
>>>>>>>>> starting from given pass.
>>>>>>>>Bike-shedding:
>>>>>>>>Would it make sense to have syntax for defining pass ranges to execute
>>>>>>>>?
>>>>>>>>for instance:
>>>>>>>>void __GIMPLE(execute (pass_start : pass_end))
>>>>>>>>which would execute all the passes within range [pass_start, pass_end],
>>>>>>>>which would be convenient if the range is large.
>>>>>>>
>>>>>>> But it would rely on a particular pass pipeline, f.e. pass-start appearing before pass-end.
>>>>>>>
>>>>>>> Currently control doesn't work 100% as it only replaces all_optimizations but not lowering passes or early opts, nor IPA opts.
>>>>>>>
>>>>>>
>>>>>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>>>>>> and early opt passes to execute. I think we have to execute some
>>>>>> passes (like cfg) anyway to represent GIMPLE into proper form
>>>>>
>>>>> Yes, that's true.  Note that early opt passes only optimize but we need
>>>>> pass_build_ssa_passes at least (for into-SSA).  For proper unit-testing
>>>>> of GIMPLE passes we do need to guard off early opts somehow
>>>>> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
>>>>> that).
>>>>>
>>>>> Then there is of course the question about IPA passes which I think is
>>>>> somewhat harder (one could always disable all IPA passes manually
>>>>> via flags of course or finally have a global -fipa/no-ipa like most
>>>>> other compilers).
>>>>>
>>>> Can we iterate through all ipa passes and do -fdisable-ipa-pass or
>>>> -fenable-ipa-pass equivalent for each?
>>>
>>> We could do that, yes.  But let's postpone this issue.  I think that
>>> startwith is going to be most useful and rather than constructing
>>> a pass list for it "native" support for it in the pass manager is
>>> likely to produce better results (add a 'startwith' member alongside
>>> the pass list member and if it is set the pass manager skips all
>>> passes that do not match 'startwith' and once it reaches it it clears
>>> the field).
>>>
>>> In the future I hope we can get away from a static pass list and more
>>> towards rule-driven pass execution (we have all those PROP_* stuff
>>> already but it isn't really used for example).  But well, that would be
>>> a separate GSoC project ;)
>>>
>>> IMHO startwith will provide everything needed for unit-testing.  We can
>>> add a flag on whether further passes should be executed or not and
>>> even a pass list like execute ("ccp1", "fre") can be implemented by
>>> startwith ccp1 and then from there executing the rest of the passes in the
>>> list and stopping at the end.
>>>
>>> As said, unit-testing should exercise a single pass if we can control
>>> its input.
>>>
>> In this patch I am skipping execution of passes until pass_startwith
>> is found. Unlike previous build, now pass manager executes all passes
>> in pipeline starting from pass_startwith instead of just sub passes.
>
> That looks good.  I wonder if
>
> +  if (startwith_p && cfun->startwith)
> +    {
> +      if (pass->name == cfun->pass_startwith->name
> +         || pass->name == "*clean_state")
>
> need better be strcmp ()s though.  Also the early optimization pipeline
> should be executed with startwith support as well.
>

This patch adds startwith support for early opt passes. But for
starting from some passes (like asan0, optimized) in all_passes
pipeline, it falils at verify_curr_properties in execute_one_pass ().
I wonder if we need to update properties after skipping each pass

Thanks,
Prasad

> Richard.
>
>>> Thanks,
>>> Richard.
>>>
>>>> Thanks,
>>>> Prasad
>>>>
>>>>> Richard.
>>>>>
>>>>>>> Richard.
>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Prathamesh
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Prasad Ghangal
>>>>>>>
>>>>>>>

Attachment: pass_man.diff
Description: Text document


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