Re: IPA branch
Mark Mitchell [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: IPA branch
Mark Mitchell [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: IPA branch
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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: IPA branch
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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: IPA branch
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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: IPA branch
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
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
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 KR style declarations. Either we can refuse functions KR 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
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 - 1.198 +++ cvs.html 4 Aug 2005 18:30:25 - @@ -145,12 +145,10 @@ generally of the form gcc-iX/i_iY dl - dta href=projects/tree-profiling.htmltree-profiling-branch/a/dt - ddThis 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 + dtipa-branch/dt + ddThis 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 dtstruct-reorg-branch/dt ddThis 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 + dta href=projects/tree-profiling.htmltree-profiling-branch/a/dt + ddThis 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 + dtbje-unsw-branch/dt ddThis 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 - 1.2 +++ projects/tree-profiling.html 4 Aug 2005 18:30:25 - @@ -6,6 +6,10 @@ body h1Improving GCC's Interprocedural Optimizaion Infrastructure/h1 +h3This page describes the work done in 2005 on the +codetree-profiling-branch/code. This branch is now retired. Work +in the same area (IPA) has continued on the codeipa-branch/code/h3 + pThis 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 codetree-profiling-branch/code./p
Re: IPA branch
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: + ddThis 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
