IPA branch

IPA branch

[Jan Hubicka]

Hi,
I've branches the IPA branch yesterday and re-directed current SPEC
testers running tree-profiling branch (now officially retired ;) to it.
( http://www.suse.de/~aj/SPEC/amd64 ).
The branch should be used for interprocedural optimization projects that
has serious chance to get into 4.2 (or perhaps longer term plans as
long as they won't interfere with merging changes to 4.1).

I plan to implement the SSA based inlining to the branch and will start
pushing patches probably sometime next week.

I would especially welcome frotend fixes for the multiple decls problems
so we can compile SPEC in whole program mode wihtout ugly hacks ;))
Please use IPA in the subject line if you don't want me to miss the
patches to branch.

Honza

Re: IPA branch

[Jan Hubicka]

> Hi,
> I've branches the IPA branch yesterday and re-directed current SPEC
> testers running tree-profiling branch (now officially retired ;) to it.
> ( http://www.suse.de/~aj/SPEC/amd64 ).
> The branch should be used for interprocedural optimization projects that
> has serious chance to get into 4.2 (or perhaps longer term plans as
> long as they won't interfere with merging changes to 4.1).
> 
> I plan to implement the SSA based inlining to the branch and will start
> pushing patches probably sometime next week.
> 
> I would especially welcome frotend fixes for the multiple decls problems
> so we can compile SPEC in whole program mode wihtout ugly hacks ;))
> Please use IPA in the subject line if you don't want me to miss the
> patches to branch.

Forgot to mention, the tag is ipa-branch ;)

Honza
> 
> Honza

Re: IPA branch

[Steven Bosscher]

On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
> > Hi,
> > I've branches the IPA branch yesterday and re-directed current SPEC
> > testers running tree-profiling branch (now officially retired ;) to it.
> > ( http://www.suse.de/~aj/SPEC/amd64 ).
> > The branch should be used for interprocedural optimization projects that
> > has serious chance to get into 4.2 (or perhaps longer term plans as
> > long as they won't interfere with merging changes to 4.1).
> >
> > I plan to implement the SSA based inlining to the branch and will start
> > pushing patches probably sometime next week.
> >
> > I would especially welcome frotend fixes for the multiple decls problems
> > so we can compile SPEC in whole program mode wihtout ugly hacks ;))
> > Please use IPA in the subject line if you don't want me to miss the
> > patches to branch.
>
> Forgot to mention, the tag is ipa-branch ;)

I guess the web pages should be updated with something like the attached?

Gr.
Steven

Index: cvs.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v
retrieving revision 1.198
diff -u -3 -p -r1.198 cvs.html
--- cvs.html	28 Jul 2005 21:09:10 -0000	1.198
+++ cvs.html	4 Aug 2005 18:30:25 -0000
@@ -145,12 +145,10 @@ generally of the form "gcc-<i>X</i>_<i>Y
 
 <dl>
 
-  <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
-  <dd>This branch is for the development of profiling heuristics
-  and profile based optimizations for trees, such as profile driven inline
-  heuristics.  Another goal of this branch is to demonstrate that maintaining
-  the CFG and profile information over expanding from GIMPLE trees to RTL
-  is feasible and can bring considerable performance improvements.</dd>
+  <dt>ipa-branch</dt>
+  <dd>This is a branch for the development interprocedural optimizations
+  such as inlining and cloning, interprocedural alias analysis, and so on.
+  This branch is being maintained by Jan Hubicka</dd>
 
   <dt>struct-reorg-branch</dt>
   <dd>This branch is for the development of structure reorganization
@@ -476,6 +474,13 @@ be prefixed with the initials of the dis
   of the passes.  It has now been merged into mainline for the
   4.1 release.</dd>
 
+  <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
+  <dd>This branch is for the development of profiling heuristics
+  and profile based optimizations for trees, such as profile driven inline
+  heuristics.  Another goal of this branch is to demonstrate that maintaining
+  the CFG and profile information over expanding from GIMPLE trees to RTL
+  is feasible and can bring considerable performance improvements.</dd>
+
   <dt>bje-unsw-branch</dt>
   <dd>This branch was dedicated to some research work by Ben Elliston
     at the University of New South Wales (UNSW) on transformation
Index: projects/tree-profiling.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-profiling.html,v
retrieving revision 1.2
diff -u -3 -p -r1.2 tree-profiling.html
--- projects/tree-profiling.html	4 Jul 2004 21:00:54 -0000	1.2
+++ projects/tree-profiling.html	4 Aug 2005 18:30:25 -0000
@@ -6,6 +6,10 @@
 <body>
 <h1>Improving GCC's Interprocedural Optimizaion Infrastructure</h1>
 
+<h3>This page describes the work done in 2005 on the
+<code>tree-profiling-branch</code>.  This branch is now retired.  Work
+in the same area (IPA) has continued on the <code>ipa-branch</code></h3>
+
 <p>This page describes ongoing work to improve GCC's infrastructure
 for tree-based interprocedural optimizers. The work is done on a
 branch in GCC's CVS repository called <code>tree-profiling-branch</code>.</p>

Re: IPA branch

[Jan Hubicka]

> On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
> > > Hi,
> > > I've branches the IPA branch yesterday and re-directed current SPEC
> > > testers running tree-profiling branch (now officially retired ;) to it.
> > > ( http://www.suse.de/~aj/SPEC/amd64 ).
> > > The branch should be used for interprocedural optimization projects that
> > > has serious chance to get into 4.2 (or perhaps longer term plans as
> > > long as they won't interfere with merging changes to 4.1).
> > >
> > > I plan to implement the SSA based inlining to the branch and will start
> > > pushing patches probably sometime next week.
> > >
> > > I would especially welcome frotend fixes for the multiple decls problems
> > > so we can compile SPEC in whole program mode wihtout ugly hacks ;))
> > > Please use IPA in the subject line if you don't want me to miss the
> > > patches to branch.
> >
> > Forgot to mention, the tag is ipa-branch ;)
> 
> I guess the web pages should be updated with something like the attached?

This looks fine to me.  Thanks!  Perhaps even cvs.html should mention
that tree-profiling was almost fully merged and retired?
Honza
> 
> Gr.
> Steven
> 
> Index: cvs.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v
> retrieving revision 1.198
> diff -u -3 -p -r1.198 cvs.html
> --- cvs.html	28 Jul 2005 21:09:10 -0000	1.198
> +++ cvs.html	4 Aug 2005 18:30:25 -0000
> @@ -145,12 +145,10 @@ generally of the form "gcc-<i>X</i>_<i>Y
>  
>  <dl>
>  
> -  <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
> -  <dd>This branch is for the development of profiling heuristics
> -  and profile based optimizations for trees, such as profile driven inline
> -  heuristics.  Another goal of this branch is to demonstrate that maintaining
> -  the CFG and profile information over expanding from GIMPLE trees to RTL
> -  is feasible and can bring considerable performance improvements.</dd>
> +  <dt>ipa-branch</dt>
> +  <dd>This is a branch for the development interprocedural optimizations
> +  such as inlining and cloning, interprocedural alias analysis, and so on.
> +  This branch is being maintained by Jan Hubicka</dd>
>  
>    <dt>struct-reorg-branch</dt>
>    <dd>This branch is for the development of structure reorganization
> @@ -476,6 +474,13 @@ be prefixed with the initials of the dis
>    of the passes.  It has now been merged into mainline for the
>    4.1 release.</dd>
>  
> +  <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
> +  <dd>This branch is for the development of profiling heuristics
> +  and profile based optimizations for trees, such as profile driven inline
> +  heuristics.  Another goal of this branch is to demonstrate that maintaining
> +  the CFG and profile information over expanding from GIMPLE trees to RTL
> +  is feasible and can bring considerable performance improvements.</dd>
> +
>    <dt>bje-unsw-branch</dt>
>    <dd>This branch was dedicated to some research work by Ben Elliston
>      at the University of New South Wales (UNSW) on transformation
> Index: projects/tree-profiling.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-profiling.html,v
> retrieving revision 1.2
> diff -u -3 -p -r1.2 tree-profiling.html
> --- projects/tree-profiling.html	4 Jul 2004 21:00:54 -0000	1.2
> +++ projects/tree-profiling.html	4 Aug 2005 18:30:25 -0000
> @@ -6,6 +6,10 @@
>  <body>
>  <h1>Improving GCC's Interprocedural Optimizaion Infrastructure</h1>
>  
> +<h3>This page describes the work done in 2005 on the
> +<code>tree-profiling-branch</code>.  This branch is now retired.  Work
> +in the same area (IPA) has continued on the <code>ipa-branch</code></h3>
> +
>  <p>This page describes ongoing work to improve GCC's infrastructure
>  for tree-based interprocedural optimizers. The work is done on a
>  branch in GCC's CVS repository called <code>tree-profiling-branch</code>.</p>

Re: IPA branch

[Gerald Pfeifer]

On Fri, 5 Aug 2005, Jan Hubicka wrote:
>> I guess the web pages should be updated with something like the attached?

Yes...

> This looks fine to me.  Thanks!  Perhaps even cvs.html should mention
> that tree-profiling was almost fully merged and retired?

...and, yes. ;-)

Minor comments for the original patch:

> > +  <dd>This is a branch for the development interprocedural optimizations
> > +  such as inlining and cloning, interprocedural alias analysis, and so on.
> > +  This branch is being maintained by Jan Hubicka</dd>

"for the development of...", and can you add a full stop at the end?

Gerald

Re: IPA branch

[Razya Ladelsky]

Mark Mitchell <mark@codesourcery.com> wrote on 29/09/2006 01:55:24:

> Razya Ladelsky wrote:
> 
> > Except for new optimizations, IPCP (currently on mainline) should also 
be 
> > transformed to SSA.
> > IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3 

> > after IPA branch 
> > is committed and some testsuite regressions failing with 
> > IPCP+versioning+inlining are fixed.
> 
> Is there a project page for this work?
> 

Mark,

I integrated SSA IPCP as part of IPA branch page, as it seems the most 
natural place.
IPCP code and also versioning code (used by IPCP and by the inliner) have 
to be translated into
SSA, and so there's a big correlation among the parts.
http://gcc.gnu.org/wiki/ipa-branch

Thanks,
Razya

> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Re: IPA branch

[Razya Ladelsky]

Mark Mitchell <mark@codesourcery.com> wrote on 29/09/2006 01:55:24:

> Razya Ladelsky wrote:
> 
> > Except for new optimizations, IPCP (currently on mainline) should also 
be 
> > transformed to SSA.
> > IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3 

> > after IPA branch 
> > is committed and some testsuite regressions failing with 
> > IPCP+versioning+inlining are fixed.
> 
> Is there a project page for this work?
> 

No, I haven't put a page for this work yet.
Will do so when I get back on Tuesday.
Just thought it's a part of maintaining IPCP after IPA branch changes.

Thanks,
Razya


> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Re: IPA branch

[Mark Mitchell]

Jan Hubicka wrote:

> I intended to write the overview in a way to express that some work will
> be needed.

Thank you for the detailed explanation.  I think your plans all sound 
reasonable.  I would definitely encourage you to start preparing patches 
and submitting them for review -- and hounding reviewers! -- as soon as 
possible.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: IPA branch

[Mark Mitchell]

Razya Ladelsky wrote:

> Except for new optimizations, IPCP (currently on mainline) should also be 
> transformed to SSA.
> IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3 
> after IPA branch 
> is committed and some testsuite regressions failing with 
> IPCP+versioning+inlining are fixed.

Is there a project page for this work?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: IPA branch

[Jan Hubicka]

> Jan --
> 
> I'm trying to plan for GCC 4.3 Stage 1.  The IPA branch project is 
> clearly a good thing, and you've been working on it for a long time, so 
> I'd really like to get it into GCC 4.3.  However, I'm a little 
> concerned, in reading the project description, that it's not all that 
> far along.  I'm hoping that I'm just not reading the description well, 
> and that you can explain things in a way that makes it obvious to me 
> that the work is actually almost done.
> 
> The Wiki page says "first part of patches was already sent", but I can't 
> tell how much that is, or how many of the "modifications required" steps 
> are already done.  Have you completed all the work on the IPA branch 
> itself, so that it's just a problem of merging?  How much of the merging 
> have you actually done?  What version of mainline corresponds to the 
> root of the IPA branch?  Have maintainers with appropriate write 
> privileges reviewed the patches?

Mark,
I intended to write the overview in a way to express that some work will
be needed. In general IPA branch infrastructure is done (and was done
for last version too, I just was traveling and doing scientific work
during almost whole stage 1) and the branch was synchronized with
mainline two weeks ago. It was also used for building SPEC/c++
benchmarks on IA-64/x86 and by Haifa people on PPC so it received some
testing. There is some bitrot from long merging and little SVN problem I
got shortly after summit, but I plan to clean this up while reviewing
the whole diff next week.

I think that rest of work needs to be done on-the-fly while merging as
there are involved interfaces that are touching plans of multiple people

The patch I am referring to is
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00567.html that is by far
the most noisy patch from the planned series.  I am planning to merge
the branch incrementally (same way as I did for all my past work) -
first localizing the variables, then adding infrastructure for holding
multiple SSA forms, teaching inliner to handle both SSA and non-SSA and
finally switch to it.  Then the optimizations from Haifa folks and my
inliner changes can go in independently.  

I was trying to take care to keep the things organized in a way so the
merge should be relatively safe ie if we stop in middle - I hope we
won´t, we won´t end up with too much dead code or compiler ready for
complete revert) The non-SSA path needs to be preserved for -O0
compilation and the inliner simply handles the SSA datastructures as
additional IL feature rather than having two different implementations
of same thing.

What I am most concerned about is the second step as there are some
datastructure changes (in particular the annotations on variables needs
to be partly privatized as they are shared across multiple functions for
static variables). IPA branch does it in a somewhat kludgy way I
discussed with rth and Diego on the summit.  (I simply keep the
annotations around for static variables for duration of whole
compilation but most of data are reset when new function is being
compiled, that is bit nonsential memory-wise)

While we don't have much better answer (other posibility discussed with
rth is simply bring all annotations to on-side hashtable and modify the
single accestor function, that is cleaner in design but more exensive
way to get into same place). It is probably desirable to move away from
annotations, so I would like to have some time in stage1 to simply drop
off as much as possible making my kludge smaller.  So the plan would be
to do incremental changes to move the pass local data present in
annotations (actually almost everything except for pointer analysis
information) into on-the-side datastructures that is now hopefully
official plan to reduce memory usage too.

The inliner changes/passmanager changes should be all pretty much fine -
only problems I hit there is that inliner occasionally needs fixing
because it does more constant propagation than mainline (instead of
const declared variables, I do all direct uses of SSA name of incomming
parameter) and the constant propagation in inliner is a bit broken,
but most of fixes was pushed upstream and I didn't seen any for a longer
while. There was other issues with SSA updating across EH edges, but we
resolved it on the summit with rth.

There was no reviews from maintainers so far (I hoped to get ones while
possibly merging the stuff to LTO branch), but I hope it will go
fluently ;)) I also organized my plans so I will be in Prague from day
after tomorrow to November and should have time for stage1 work.

Honza
> 
> I'm not in any way trying to send a negative signal about this work.  I 
> have every hope that it will be merged soon.  I just want to better 
> understand the situation.
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

IPA branch

[Mark Mitchell]

Jan --

I'm trying to plan for GCC 4.3 Stage 1.  The IPA branch project is 
clearly a good thing, and you've been working on it for a long time, so 
I'd really like to get it into GCC 4.3.  However, I'm a little 
concerned, in reading the project description, that it's not all that 
far along.  I'm hoping that I'm just not reading the description well, 
and that you can explain things in a way that makes it obvious to me 
that the work is actually almost done.

The Wiki page says "first part of patches was already sent", but I can't 
tell how much that is, or how many of the "modifications required" steps 
are already done.  Have you completed all the work on the IPA branch 
itself, so that it's just a problem of merging?  How much of the merging 
have you actually done?  What version of mainline corresponds to the 
root of the IPA branch?  Have maintainers with appropriate write 
privileges reviewed the patches?

I'm not in any way trying to send a negative signal about this work.  I 
have every hope that it will be merged soon.  I just want to better 
understand the situation.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: IPA branch

[Jan Hubicka]

> On Saturday 06 August 2005 08:14, Andrew Pinski wrote:
> > On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote:
> > > Hi,
> > >
> > > Patch from Michael Matz
> > > (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes
> > > the multiple decls problems.
> >
> > That will only help with the fortran problem,
> That is the only problem we have to care about, isn't it?  The C++
> front-end folks can fix their own front end.

There is also problem with the C frontend and K&R style declarations.
Either we can refuse functions K&R declared in one unit and properly
declared in other unit or we create duplicated decls...  Both is quite
wrong :(

Honza
> 
> Gr.
> Steven

Re: IPA branch

[Steven Bosscher]

On Saturday 06 August 2005 08:14, Andrew Pinski wrote:
> On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote:
> > Hi,
> >
> > Patch from Michael Matz
> > (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes
> > the multiple decls problems.
>
> That will only help with the fortran problem,
That is the only problem we have to care about, isn't it?  The C++
front-end folks can fix their own front end.

Gr.
Steven

Re: IPA branch

[Andrew Pinski]

On Aug 5, 2005, at 9:24 PM, Canqun Yang wrote:

> Hi,
>
> Patch from Michael Matz 
> (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes
> the multiple decls problems.

That will only help with the fortran problem,  the C++ front-end have 
the same
issue.  The C front-end have still some issues but most of the problems 
with
multiple decls in the C front-end was fixed in 4.0.0.

-- pinski

Re: IPA branch

[Canqun Yang]

Hi,

Patch from Michael Matz (http://gcc.gnu.org/ml/fortran/2005-07/msg00331.html) may partly fixes 
the multiple decls problems.

I've tested and tuned this patch. It works, small functions can be inlined after DECL_INLINE 
flags (build_function_decl in trans-decl.c) have been set for them. The only regression is 
FORTRAN 95 testcase function_modulo_1.f90, it produces a wong result. 


Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.