Basile, I understand your constraints and concerns.
I personally would also be happy to see ICI and pass manager in GCC soon, BUT it was delay on our side that prevented submission/checking of the patch, so I am just taking a pragmatic approach of preparing an ICI patch first (well, actually not me but Joern who is now working full time on that), testing it and then submitting it and discussing with everyone and you if it's reasonable. ONLY THEN, depending if the changes are small and if GCC 4.5.0 is not yet closed, we will negotiate to move it to the mainline. But at the moment, before submitting it, it's just a gamble if it can go through or not and I personally don't want to do that because we will annoy all other GCC people who are working hard to make current GCC stable ... So, let's continue ICI discussions as soon as the ICI patch is ready ;) ... Cheers, Grigori > -----Original Message----- > From: Basile STARYNKEVITCH [mailto:bas...@starynkevitch.net] > Sent: Saturday, November 07, 2009 3:45 PM > To: Richard Guenther > Cc: Grigori Fursin; Steven Bosscher; Diego Novillo; Rafael Espindola; gcc; > Joern Rennecke; > Zbigniew Chamski > Subject: Re: new plugin events > > Richard Guenther wrote: > > On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin <grigori.fur...@inria.fr> > > wrote: > >> Hi Basile et al, > >> > >>> My suggestion to ICI friends is : just propose quickly your needed plugin > >>> events, and make > >>> your ICI a GPLv3 plugin. > >>> When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings > >>> some value, GCC > >>> people will perhaps start to > >>> listen and look inside. > > >> Just to mention that I am a bit confused because I actually don't expect > >> to have problems > moving > >> ICI to the mainline unless we find some big bugs that can change GCC > >> behavior (but I really > don't > >> think so). > >> We had many online and offline discussions to move ICI to the mainline GCC > >> in the last few > years > >> with GCC > >> colleagues/maintainers. We just sadly got delayed at INRIA this summer due > >> to different > reasons but > >> Joern > >> is now working with us for 2 months fully time to clean and test ICI and > >> submit patches as > soon as > >> they are ready. > >> > >> It's true that we actually need a few hooks and Joern will communicate > >> about that shortly > BUT these > >> hooks are > >> already used in real plugins for real performance tuning (in a way as > >> current hooks are > used in > >> Dehydra > >> for real program analysis in several companies). > > > > And I don't expect problems in adding hooks that ICI needs. I expect > > that ICI is a reason to improve GCCs pass manager - and I expect that > > we will improve GCCs pass manager not by simply adding hooks to it > > to "fix" it from inside plugins, but I expect that we'll get a more powerful > > pass manager _inside_ GCC. I also expect or at least hope that more > > parts of the compilation process get driven by the pass manager rather > > than by ad-hoc code gluing several phases of pass manager driven > > stages. > > We probably all agree on goals, but perhaps less on timeline. > > My feeling (but I admit I don't understand well what stage 3 means precisely > for gcc 4.5.0, in > particular w.r.t. plugins > & pass management, and why exactly stage 2 was skipped in 4.5) was up to now: > > 1. Only very small patches can go into 4.5. So ICI pass manager won't go into > 4.5.0, and any > improved pass manager won't > go into 4.5.0, only in 4.6.0. This probably means in last quarter of 2010 or > first quarter of > 2011, since 4.4.0 was > released in april 2009, and 4.3.0 was released in march 2008 and 4.2.0 was > released in may > 2007 and 4.1.0 at end of > february 2006. I am guessing 4.5.0 would be released for christmas 2009 at > the earliest, so > 4.6.0 would go out at end of > 2010 in the best case. > > 2. I was hoping that the few PLUGIN_* hooks absolutely needed by ICI could go > into 4.5. My > intuition is that it really > means small unobtrusive patches which might be accepted before Christmas 2009. > > In other words, are there hope to delay 4.5.0 release for a month to get the > ICI-improved pass > manager inside it? In > case the answer is yes, will we keep the same interface, so that the > interface for > PLUGIN_PASS_MANAGER_SETUP won't > change with the improved pass manager? > register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, > NULL, &pass_info); > with the same pass_info as documented today in > http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins ? > > > So perhaps I am simply not understanding what means the current stage 3 of > trunk (ie future > 4.5). I admit I did not > understood exactly why stage 2 disappeared (or perhaps we call today stage 3 > what was called > stage 2 or stage 3 a year > ago?). And perhaps I am wrongly guessing the release date of 4.5.0. Of > course, if 4.5.0 is > released in june 2010 things > are different! > > I suppose that ICI friends will be happy if they can hope to push a new pass > manager inside > 4.5. My personal guess was > that this is hopeless - they need to wait for 4.6. I would be delighted to be > wrong, and as > Richard and others I would > be extremely happy with a new pass manager. > > I think MELT can cope with any reasonable evolution of the pass manager. > > I believe (only my opinion) that ICI people care a lot about being able or > not to push an > improved pass manager inside > 4.5 or only inside 4.6. That makes a one year difference, and I guess one > year is not > insignificant to them. > > Regards. > > PS. BTW, I find that speaking of stages with number is confusing (especially > since now stage 3 > goes right after stage > 1). I would much prefer named stages, like "major change stage", "minor > improvement stage", > "bug fix stage". > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} ***
