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.
Thanks,
Richard.
> Thanks,
> Prasad
>
>> Richard.
>>
>>>> Richard.
>>>>
>>>>>Thanks,
>>>>>Prathamesh
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Prasad Ghangal
>>>>
>>>>
