On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal <prasad.ghan...@gmail.com> wrote:
> On 6 July 2016 at 14:24, Richard Biener <richard.guent...@gmail.com> wrote:
>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal <prasad.ghan...@gmail.com>
>> wrote:
>>> On 30 June 2016 at 17:10, Richard Biener <richard.guent...@gmail.com> wrote:
>>>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>>>> <prasad.ghan...@gmail.com> wrote:
>>>>> On 29 June 2016 at 22:15, Richard Biener <richard.guent...@gmail.com>
>>>>> wrote:
>>>>>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>>>>>> <prathamesh.kulka...@linaro.org> wrote:
>>>>>>>On 18 June 2016 at 12:02, Prasad Ghangal <prasad.ghan...@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.
Richard.
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Prasad
>>>
>>>> Richard.
>>>>
>>>>>> Richard.
>>>>>>
>>>>>>>Thanks,
>>>>>>>Prathamesh
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Prasad Ghangal
>>>>>>
>>>>>>
