GCC 4.9.4 Status Report (2016-07-18)
Status == The GCC 4.9 branch is still open for regression and documentation fixes but given GCC 6.2 is close it's about time to close the branch with a last release from it. Thus in the next week I plan to do a RC for GCC 4.9.4 following with a release and the branch closing game. Please consider backporting of important fixes (wrong-code, rejects-valid) but err on the side of caution. Quality Data Priority # Change from last report --- --- P10 P2 140 + 40 P3 41 + 16 P4 66 + 2 P5 30 - 3 --- --- Total P1-P3 181 + 56 Total 277 + 51 Previous Report === https://gcc.gnu.org/ml/gcc/2015-06/msg00260.html
[DOC, RFC] Partial integration of sections: 3.18.54 x86 Options and 6.31.32 x86 Function Attributes
Hello. As mentioned in [1], we does not fully cover all i386 target options in [2]. Apart from that, flag explanation is more brief than we've got in [3]. One example: [3]: -mrecip This option enables use of RCPSS and RSQRTSS instructions (and their vectorized variants RCPPS and RSQRTPS) with an additional Newton-Raphson step to increase precision instead of DIVSS and SQRTSS (and their vectorized variants) for single-precision floating-point arguments. These instructions are generated only when -funsafe-math-optimizations is enabled together with -ffinite-math-only and -fno-trapping-math. Note that while the throughput of the sequence is higher than the throughput of the non-reciprocal instruction, the precision of the sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994). Note that GCC implements 1.0f/sqrtf(x) in terms of RSQRTSS (or RSQRTPS) already with -ffast-math (or the above option combination), and doesn't need -mrecip. Also note that GCC emits the above sequence with additional Newton-Raphson step for vectorized single-float division and vectorized sqrtf(x) already with -ffast-math (or the above option combination), and doesn't need -mrecip. [2]: ‘recip’ ‘no-recip’ Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and RSQRTPS instructions followed an additional Newton-Raphson step instead of doing a floating-point division. I'm thinking whether it would be possible to tell that 'target (options)' accepts all options as mentioned in [3], expect ... If it's acceptable opinion, I can prepare a patch. Thanks, Martin [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652#c4 [2] https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes [3] https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html#x86-Options
Re: [gimplefe] hacking pass manager
On 15 July 2016 at 16:13, Richard Biener wrote:
> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
> wrote:
>> On 8 July 2016 at 13:13, Richard Biener wrote:
>>> 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 opt
Re: [gimplefe] hacking pass manager
On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal
wrote:
>On 15 July 2016 at 16:13, Richard Biener
>wrote:
>> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>> wrote:
>>> On 8 July 2016 at 13:13, Richard Biener
>wrote:
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_
Re: [gimplefe] hacking pass manager
On 19 July 2016 at 00:25, Richard Biener wrote:
> On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal
> wrote:
>>On 15 July 2016 at 16:13, Richard Biener
>>wrote:
>>> On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
>>> wrote:
On 8 July 2016 at 13:13, Richard Biener
>>wrote:
> 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 startin
Re: [gimplefe] hacking pass manager
On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
> On 19 July 2016 at 00:25, Richard Biener
> wrote:
> > 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
> > > > 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
> > > 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
> >
Re: [gimplefe] hacking pass manager
On July 18, 2016 11:05:58 PM GMT+02:00, David Malcolm
wrote:
>On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
>> On 19 July 2016 at 00:25, Richard Biener
>> wrote:
>> > 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
>> > > > 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
>> > > 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).
>> > > > > > > > > >
>> > >
