On 15 July 2016 at 16:13, Richard Biener <richard.guent...@gmail.com> wrote:
> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
> <prasad.ghan...@gmail.com> wrote:
>> On 8 July 2016 at 13:13, Richard Biener <richard.guent...@gmail.com> wrote:
>>> 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.
>>>
>>
>> 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.
>
I am little confused here about parsing 'i.1' because lexer drops DOT
token for syntax like NAME.NUMBER . Hence instead of 'i.1' parser
receives 'i1'
> 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
>>>>>>>>>
>>>>>>>>>
