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 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).
For ordering of ipa passes, we could perhaps pass them via command line:
sth like -fipa-opts-order=cp,icf
which will only run ipa-cp and ipa-icf, but it admittedly looks quite ugly :/

Alternatively a more general approach would be to define pass ordering
in separate file (which could perhaps take the format of passes.def)
and that could be passed to the the compiler via command-line, say
-fpass-list=<file>
and then the compiler would parse the file and set up the pass lists
accordingly.
Not sure if this is a good solution either.

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


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