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 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.

> 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]