On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal
<prasad.ghan...@gmail.com> wrote:
>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'
Are you sure? You should get three tokens, one for 'i', one for the dot and
One for '1'. You'd lookup the first via the C frontend symbol table only.
Richard.
>> 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
>>>>>>>>>>
>>>>>>>>>>
