Razya Ladelsky/Haifa/IBM wrote on 27/09/2006 14:27:18: >
> > > > > 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. > 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. Razya > 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
