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} ***
