On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal wrote:
> On 6 July 2016 at 14:24, Richard Biener wrote:
>> On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
>> wrote:
>>> On 30 June 2016 at 17:10, Richard Biener wrote:
On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
wrote:
> On 29 June 2016 at 22:15, Richard Biener
> wrote:
>> On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
>> wrote:
>>>On 18 June 2016 at 12:02, Prasad Ghangal
>>>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.
Richard.
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Prasad
>>>
Richard.
>> Richard.
>>
>>>Thanks,
>>>Prathamesh
Thanks,
Prasad Ghangal
>>
>>
