This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: new plugin events


That's very reasonable and it's our eventual goal too so we will start discussions 
about that in detail whenever ICI is clean. 

By the way, just to mention that I am working with a student (Yuri) to
provide/understand/describe/characterize 
performance dependencies and interaction between passes using ICI to be able to make selection 
and ordering of passes more systematic and avoid having the same multiple passes in the compilation
sequence 
just because they may potentially improve the code. We use ICI with GSOC'09 extensions and is it so
far very 
simple to manipulate passes through plugins (we use XML outside to save all IP passes and passes per
function). 
This is a long term project, but as soon as we have some promising results, we will tell you ;) ...

Cheers,
Grigori

> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: Saturday, November 07, 2009 3:06 PM
> To: Grigori Fursin
> Cc: Basile STARYNKEVITCH; Steven Bosscher; Diego Novillo; Rafael Espindola; gcc; Joern
> Rennecke; Zbigniew Chamski
> Subject: Re: new plugin events
> 
> On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin <grigori.fursin@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.
> 
> Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]