This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gimplefe] hacking pass manager
On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> 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
Yeah, it's not possible to start at arbitrary points with skipping passes
that provide a required property. I suspect it's good enough that we'll
ICE if that happens.
I see you are working on the dump-file side a bit now. What is still
missing after you got support for PHIs is parsing of SSA names.
Without this unit-testing will be difficult at best.
I think what we need to do is simplify the job of the parser and
make the syntax we use to print SSA names a bit different.
So rather than printing VAR_VERSION we need to choose a
letter that is not part of a valid identifier before VERSION,
like a dot '.'. Thus we'd have i.1 instead of i_1 and we'd have
.2 instead of _2 for an anonymous SSA name. The advantage
for non-anonymous names is that we can properly re-use the
C frontends decl handling for declaring and looking up 'i'.
The disadvantage is that for anonymous SSA names this isn't
so easy which means we could choose to not support those
for the moment and require fake decls for them. In fact
into-SSA will do the correct thing if we just treat them as decls,
thus continue to dump them as _VERSION.
Another issue would be to preserve SSA name VERSIONS
(the decl idea for anon ones doesn't work) or basic-block
numbering/ordering (requires direct CFG construction). Both
are out-of-scope for the GSoC project I think.
Richard.
> Thanks,
> Prasad
>
>> Richard.
>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>> Thanks,
>>>>> Prasad
>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>>>Thanks,
>>>>>>>>>Prathamesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Prasad Ghangal
>>>>>>>>
>>>>>>>>