Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Dorit Nuzman]

Dear all,

We would like to share notes from the lively panel discussion at
GROW'10 (GCC Research Opportunities Workshop) that took place at the
end of January in Pisa, Italy (alongside the HiPEAC conference).
The main topic of the discussion was:

      How to make GCC more attractive to researchers,
      and how GCC can benefit from researchers?

Here is the list of major points and wishes raised by participants:

* Need to encourage cleanup/infrastructure work on GCC and provide
stable/flexible/extensible APIs (the question is how to encourage such
infrastructure work...?)

* Encourage people to work on infrastructure and full implementation
that actually works: Lobby for high quality conferences to reserve a quota
of the accepted papers to papers that focus on *implementation* work (and
start with HiPEAC!)

* Follow up to the above: Encourage research that actually works:
Lobby for conferences to favor research work that is tested on a realistic
environment (e.g. pass all of SPECcpu...), and that is reproducible.
Then GCC and the community could immediately benefit from the results and
not wait for many years before someone decides to reproduce/redo research
ideas in GCC.

* Get statistics on percentage of papers/projects that use compilers other
than GCC, and ask them why... (By the way, why was OpenCL implemented only
on LLVM and not on GCC?)

* Open up GCC to be used as a library by other tools, so that other tools
could use its analysis facilities. For example, having alias analysis as an
API rather than a pass that needs to be applied and then collect
information. Allow developers/tools access those functions outside GCC
(should be a high-level API).

* Follow up to the above: Need to come up with a common API /
standardization / common levels of abstractions. Decide on how to
coordinate efforts and find commonalities.

* Need a simple pass manager that can list all available passes
and allow any scheduling (providing dependency information).

* Make more visible/accessible guides for building/extending GCC.

* Better advertize Google Summer of Code, and provide more mentoring.

* Send feedback on which plugin events are desired to add to next releases
of GCC.

* GCC tries to auto-parallelize the programs it compiles. Will GCC itself
be made more multi-threaded and run faster in a multi-core environment...?


We've collected these and other comments/suggestions before/at/after the
workshop, on the GROW'10 wiki page:
http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Questions



We hope these notes would help improve GCC and its appeal/usability for
researches (or at least raise more discussion!)

Yours,
Grigori Fursin and Dorit Nuzman
(GROW'10 organizers)

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Chris Lattner]

On Apr 11, 2010, at 5:54 AM, Dorit Nuzman wrote:
> 
> * Get statistics on percentage of papers/projects that use compilers other
> than GCC, and ask them why...

Hi Dorit,

Here is a semi reasonably list of llvm-based publications: http://llvm.org/pubs/ which might be useful.

>  (By the way, why was OpenCL implemented only on LLVM and not on GCC?)

There are many reasons, but one of the biggest is the GCC doesn't (practically speaking) support JIT compilation.  While it is possible to implement OpenCL on GCC, I suspect that the end result wouldn't be very compelling without some major architecture changes.

-Chris

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Thanks, Chris!

At GROW'10 panel, we have been discussing how to make GCC more attractive to researchers
and to start listing features that are important to researchers and missing in GCC but present 
in other compilers. Maybe we should also make a "Publications" wiki page on GCC 
website and start collecting references to papers where GCC has been used - however, the
most important part will be to provide details on important or missing features, not just 
list publications ...

As for OpenCL and lack of JIT support in GCC, we have been effectively overcoming this problem 
for many years using static multi-versioning and run-time version selection based on program
and system behavior (even though there are obvious limitations), 
so I guess we can temporally continue using similar techniques for OpenCL in GCC...
 
By the way, I remember that when we had first discussions to include plugin framework to GCC some
years ago, 
first feedback was extremely negative. Nevertheless, GCC 4.5 will feature plugin framework (that
will 
also be very useful for research), so maybe GCC will support JIT compilation too one day ;) ...

Cheers,
Grigori


-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Chris Lattner
Sent: Sunday, April 11, 2010 8:15 PM
To: Dorit Nuzman
Cc: gcc@gcc.gnu.org
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On Apr 11, 2010, at 5:54 AM, Dorit Nuzman wrote:
> 
> * Get statistics on percentage of papers/projects that use compilers other
> than GCC, and ask them why...

Hi Dorit,

Here is a semi reasonably list of llvm-based publications: http://llvm.org/pubs/ which might be
useful.

>  (By the way, why was OpenCL implemented only on LLVM and not on GCC?)

There are many reasons, but one of the biggest is the GCC doesn't (practically speaking) support JIT
compilation.  While it is possible to implement OpenCL on GCC, I suspect that the end result
wouldn't be very compelling without some major architecture changes.

-Chris

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Chris Lattner]

On Apr 11, 2010, at 12:05 PM, Grigori Fursin wrote:
> By the way, I remember that when we had first discussions to include plugin framework to GCC some
> years ago, 
> first feedback was extremely negative. Nevertheless, GCC 4.5 will feature plugin framework (that
> will 
> also be very useful for research), so maybe GCC will support JIT compilation too one day ;) ...

Sure, I'm not saying that GCC won't make amazing infrastructure improvements, just explaining why opencl implementors didn't want to block on waiting for it to happen.

> As for OpenCL and lack of JIT support in GCC, we have been effectively overcoming this problem 
> for many years using static multi-versioning and run-time version selection based on program
> and system behavior (even though there are obvious limitations), 
> so I guess we can temporally continue using similar techniques for OpenCL in GCC...

I don't think that this is sufficient to implement OpenCL-the-spec well.  You can definitely add support for opencl-the-kernel-language, but that's only half of OpenCL: the runtime, GPU integration, and OpenGL integration aspects are just as important.  You can definitely implement all this by forking out to an assembler etc, the implementation will just not be great.

-Chris

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Sure, Chris, I agree ... 

Still, I hope that those incremental improvements will continue even if they
may not be immediately useful or fully operational ...

Cheers,
Grigori

-----Original Message-----
From: Chris Lattner [mailto:clattner@apple.com] 
Sent: Sunday, April 11, 2010 9:38 PM
To: Grigori Fursin
Cc: 'Dorit Nuzman'; gcc@gcc.gnu.org
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On Apr 11, 2010, at 12:05 PM, Grigori Fursin wrote:
> By the way, I remember that when we had first discussions to include plugin framework to GCC some
> years ago, 
> first feedback was extremely negative. Nevertheless, GCC 4.5 will feature plugin framework (that
> will 
> also be very useful for research), so maybe GCC will support JIT compilation too one day ;) ...

Sure, I'm not saying that GCC won't make amazing infrastructure improvements, just explaining why
opencl implementors didn't want to block on waiting for it to happen.

> As for OpenCL and lack of JIT support in GCC, we have been effectively overcoming this problem 
> for many years using static multi-versioning and run-time version selection based on program
> and system behavior (even though there are obvious limitations), 
> so I guess we can temporally continue using similar techniques for OpenCL in GCC...

I don't think that this is sufficient to implement OpenCL-the-spec well.  You can definitely add
support for opencl-the-kernel-language, but that's only half of OpenCL: the runtime, GPU
integration, and OpenGL integration aspects are just as important.  You can definitely implement all
this by forking out to an assembler etc, the implementation will just not be great.

-Chris=

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Hi all,

Dorit and I just got an anonymous ;) feedback about GCC vs LLVM following
our email about GROW'10 panel questions so we are just forwarding it here
(non-edited):

The reasons I have seen for using llvm/clang are basically two-fold: gcc is too slow and too
complicated. (This is true even for a company with significant in-house gcc expertise.) The C
language parser for llvm (clang) is far faster than the gcc equivalent, easier to modify, and easier
to build into a separate library. Speed is a major decision for choosing clang/llvm, as OpenCL needs
to be complied on the fly. The llvm infrastructure is also far easier to manipulate and modify than
gcc. This is particularly important as implementing OpenCL means building complier backends to
generate Nvidia's PTX or AMD's IL, adding specific vector extensions, and supporting various
language intrinsics. I don't know how much of an issue the licensing issues may be. These issues,
plus significant corporate backing, appear to be really driving llvm in the OpenCL area. My
impression is that for gcc to be competitive it will have to offer both comparable compilation speed
and dramatically better code optimizations. Even then, I'm not sure if the difficulty of working
with it will be considered a good tradeoff for most companies.

Cheers,
Grigori


-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Dorit Nuzman
Sent: Sunday, April 11, 2010 2:54 PM
To: gcc@gcc.gnu.org
Subject: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)


Dear all,

We would like to share notes from the lively panel discussion at
GROW'10 (GCC Research Opportunities Workshop) that took place at the
end of January in Pisa, Italy (alongside the HiPEAC conference).
The main topic of the discussion was:

      How to make GCC more attractive to researchers,
      and how GCC can benefit from researchers?

Here is the list of major points and wishes raised by participants:

* Need to encourage cleanup/infrastructure work on GCC and provide
stable/flexible/extensible APIs (the question is how to encourage such
infrastructure work...?)

* Encourage people to work on infrastructure and full implementation
that actually works: Lobby for high quality conferences to reserve a quota
of the accepted papers to papers that focus on *implementation* work (and
start with HiPEAC!)

* Follow up to the above: Encourage research that actually works:
Lobby for conferences to favor research work that is tested on a realistic
environment (e.g. pass all of SPECcpu...), and that is reproducible.
Then GCC and the community could immediately benefit from the results and
not wait for many years before someone decides to reproduce/redo research
ideas in GCC.

* Get statistics on percentage of papers/projects that use compilers other
than GCC, and ask them why... (By the way, why was OpenCL implemented only
on LLVM and not on GCC?)

* Open up GCC to be used as a library by other tools, so that other tools
could use its analysis facilities. For example, having alias analysis as an
API rather than a pass that needs to be applied and then collect
information. Allow developers/tools access those functions outside GCC
(should be a high-level API).

* Follow up to the above: Need to come up with a common API /
standardization / common levels of abstractions. Decide on how to
coordinate efforts and find commonalities.

* Need a simple pass manager that can list all available passes
and allow any scheduling (providing dependency information).

* Make more visible/accessible guides for building/extending GCC.

* Better advertize Google Summer of Code, and provide more mentoring.

* Send feedback on which plugin events are desired to add to next releases
of GCC.

* GCC tries to auto-parallelize the programs it compiles. Will GCC itself
be made more multi-threaded and run faster in a multi-core environment...?


We've collected these and other comments/suggestions before/at/after the
workshop, on the GROW'10 wiki page:
http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Questions



We hope these notes would help improve GCC and its appeal/usability for
researches (or at least raise more discussion!)

Yours,
Grigori Fursin and Dorit Nuzman
(GROW'10 organizers)

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Steven Bosscher]

Hi,

You know, I'm getting pretty fed up with all this LLVM advocacy on a
GCC list. It's distracting and counter-productive.

It is not as if anything mentioned in this feedback is new and not
already known here on the GCC list. Repeating the long list of known
problems won't help GCC.

Can we now please return to discussions about GCC here? Please?

Ciao!
Steven




On Wed, Apr 14, 2010 at 4:23 PM, Grigori Fursin <gfursin@gmail.com> wrote:
> Hi all,
>
> Dorit and I just got an anonymous ;) feedback about GCC vs LLVM following
> our email about GROW'10 panel questions so we are just forwarding it here
> (non-edited):
>
> The reasons I have seen for using llvm/clang are basically two-fold: gcc is too slow and too
> complicated. (This is true even for a company with significant in-house gcc expertise.) The C
> language parser for llvm (clang) is far faster than the gcc equivalent, easier to modify, and easier
> to build into a separate library. Speed is a major decision for choosing clang/llvm, as OpenCL needs
> to be complied on the fly. The llvm infrastructure is also far easier to manipulate and modify than
> gcc. This is particularly important as implementing OpenCL means building complier backends to
> generate Nvidia's PTX or AMD's IL, adding specific vector extensions, and supporting various
> language intrinsics. I don't know how much of an issue the licensing issues may be. These issues,
> plus significant corporate backing, appear to be really driving llvm in the OpenCL area. My
> impression is that for gcc to be competitive it will have to offer both comparable compilation speed
> and dramatically better code optimizations. Even then, I'm not sure if the difficulty of working
> with it will be considered a good tradeoff for most companies.
>
> Cheers,
> Grigori
>
>
> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Dorit Nuzman
> Sent: Sunday, April 11, 2010 2:54 PM
> To: gcc@gcc.gnu.org
> Subject: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
>
>
> Dear all,
>
> We would like to share notes from the lively panel discussion at
> GROW'10 (GCC Research Opportunities Workshop) that took place at the
> end of January in Pisa, Italy (alongside the HiPEAC conference).
> The main topic of the discussion was:
>
>      How to make GCC more attractive to researchers,
>      and how GCC can benefit from researchers?
>
> Here is the list of major points and wishes raised by participants:
>
> * Need to encourage cleanup/infrastructure work on GCC and provide
> stable/flexible/extensible APIs (the question is how to encourage such
> infrastructure work...?)
>
> * Encourage people to work on infrastructure and full implementation
> that actually works: Lobby for high quality conferences to reserve a quota
> of the accepted papers to papers that focus on *implementation* work (and
> start with HiPEAC!)
>
> * Follow up to the above: Encourage research that actually works:
> Lobby for conferences to favor research work that is tested on a realistic
> environment (e.g. pass all of SPECcpu...), and that is reproducible.
> Then GCC and the community could immediately benefit from the results and
> not wait for many years before someone decides to reproduce/redo research
> ideas in GCC.
>
> * Get statistics on percentage of papers/projects that use compilers other
> than GCC, and ask them why... (By the way, why was OpenCL implemented only
> on LLVM and not on GCC?)
>
> * Open up GCC to be used as a library by other tools, so that other tools
> could use its analysis facilities. For example, having alias analysis as an
> API rather than a pass that needs to be applied and then collect
> information. Allow developers/tools access those functions outside GCC
> (should be a high-level API).
>
> * Follow up to the above: Need to come up with a common API /
> standardization / common levels of abstractions. Decide on how to
> coordinate efforts and find commonalities.
>
> * Need a simple pass manager that can list all available passes
> and allow any scheduling (providing dependency information).
>
> * Make more visible/accessible guides for building/extending GCC.
>
> * Better advertize Google Summer of Code, and provide more mentoring.
>
> * Send feedback on which plugin events are desired to add to next releases
> of GCC.
>
> * GCC tries to auto-parallelize the programs it compiles. Will GCC itself
> be made more multi-threaded and run faster in a multi-core environment...?
>
>
> We've collected these and other comments/suggestions before/at/after the
> workshop, on the GROW'10 wiki page:
> http://cTuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Panel_Questions
>
>
>
> We hope these notes would help improve GCC and its appeal/usability for
> researches (or at least raise more discussion!)
>
> Yours,
> Grigori Fursin and Dorit Nuzman
> (GROW'10 organizers)
>
>

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

On 14 April 2010 16:34, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hi,
>
> You know, I'm getting pretty fed up with all this LLVM advocacy on a
> GCC list. It's distracting and counter-productive.

You cannot accuse Grigori/Dorit of Clang/LLVM advocacy. He is
retransmitting other people's feedback on perceived GCC problems. I
think knowing how many people are strongly unsatisfied with GCC can
help to take some future decisions, like moving to C++.

GCC is better than Clang/LLVM in many aspects but, like it or not, the
opposite is also true, and we should learn from those aspects what we
can, take what is good and drop what is bad. [1]

Otherwise, as Ian said in another topic [2]: "I have a different fear:
that gcc will become increasing irrelevant".

Manuel.

[1] A good example is the comparison of
http://people.redhat.com/bkoz/diagnostics/diagnostics.html
[2] http://gcc.gnu.org/ml/gcc/2007-11/msg00436.html

PS: On the other hand, I think that modifying GCC to suit the purposes
of dragonegg or LLVM is a *bad* idea.
PS2: That GCC developers lose temper over this, also gives a negative
image of GCC.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Steven Bosscher]

On Wed, Apr 14, 2010 at 5:18 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 14 April 2010 16:34, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> Hi,
>>
>> You know, I'm getting pretty fed up with all this LLVM advocacy on a
>> GCC list. It's distracting and counter-productive.
>
> You cannot accuse Grigori/Dorit of Clang/LLVM advocacy.

I did not mean to come across as accusing them. If I did, then I
appologize for that.

Ciao!
Steven

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Diego Novillo]

On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

> GCC is better than Clang/LLVM in many aspects but, like it or not, the
> opposite is also true, and we should learn from those aspects what we
> can, take what is good and drop what is bad. [1]

Agreed.

> Otherwise, as Ian said in another topic [2]: "I have a different fear:
> that gcc will become increasing irrelevant".

That's my impression, as well.  It is true of just about every code
base, if it cannot attract new developers, it stagnates and eventually
whithers away.

To attract new developers, GCC needs to modernize its internal
structure.  I have some thoughts on that, but progress has been slow,
due mostly to resource constraints.

Alternately, GCC could just content itself to being a legacy compiler
with a dwindling user base.  It won't happen tomorrow, but it may
happen eventually.


Diego.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Duncan Sands]

Hi Manuel,

> PS: On the other hand, I think that modifying GCC to suit the purposes
> of dragonegg or LLVM is a *bad* idea.

my policy has been to only propose GCC patches that are useful to GCC itself.
Well, yesterday I broke this rule and posted a patch that was only of interest
to dragonegg, but let's hope that this is the exception that proves the rule,
as they say :)

Ciao,

Duncan.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Nathan Froyd]

On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
> > Otherwise, as Ian said in another topic [2]: "I have a different fear:
> > that gcc will become increasing irrelevant".
> 
> That's my impression, as well.  It is true of just about every code
> base, if it cannot attract new developers, it stagnates and eventually
> whithers away.
> 
> To attract new developers, GCC needs to modernize its internal
> structure.  I have some thoughts on that, but progress has been slow,
> due mostly to resource constraints.

Would you mind expanding--even just a little bit--on what bits need
modernizing?  There's things like:

http://gcc.gnu.org/wiki/Speedup_areas

and perhaps:

http://gcc.gnu.org/wiki/general_backend_cleanup

But neither of those really touches the middle-end, which is where I
presume the grousing vis-a-vis GCC vs. LLVM is really generated from.
Or it's the front-end support.  I don't know.

I know there are ugly parts still remaining in GCC.  But my experience
(extending/parameterizing an LLVM optimization pass, writing/modifying
GCC middle-end optimization passes, some GCC backend hacking) suggests
that the complexity is similar.  I think concrete "I tried X and it
sucked" or "these are the areas of suckage" would be helpful.

-Nathan

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Richard Guenther]

On Wed, Apr 14, 2010 at 5:44 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
>> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>> > Otherwise, as Ian said in another topic [2]: "I have a different fear:
>> > that gcc will become increasing irrelevant".
>>
>> That's my impression, as well.  It is true of just about every code
>> base, if it cannot attract new developers, it stagnates and eventually
>> whithers away.
>>
>> To attract new developers, GCC needs to modernize its internal
>> structure.  I have some thoughts on that, but progress has been slow,
>> due mostly to resource constraints.
>
> Would you mind expanding--even just a little bit--on what bits need
> modernizing?  There's things like:
>
> http://gcc.gnu.org/wiki/Speedup_areas
>
> and perhaps:
>
> http://gcc.gnu.org/wiki/general_backend_cleanup
>
> But neither of those really touches the middle-end, which is where I
> presume the grousing vis-a-vis GCC vs. LLVM is really generated from.
> Or it's the front-end support.  I don't know.
>
> I know there are ugly parts still remaining in GCC.  But my experience
> (extending/parameterizing an LLVM optimization pass, writing/modifying
> GCC middle-end optimization passes, some GCC backend hacking) suggests
> that the complexity is similar.  I think concrete "I tried X and it
> sucked" or "these are the areas of suckage" would be helpful.

I think we have made good progress with cleaning up the frontend - backend
interface.  Still there remains cleanups and enhancements to be done
with the pass-manager and how it interacts with the cgraph code.

Oh, and of course some high-level overview documentation just about
that pieces are missing.

Richard.

> -Nathan
>

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Diego Novillo]

On Wed, Apr 14, 2010 at 11:44, Nathan Froyd <froydnj@codesourcery.com> wrote:
> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
>> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>> > Otherwise, as Ian said in another topic [2]: "I have a different fear:
>> > that gcc will become increasing irrelevant".
>>
>> That's my impression, as well.  It is true of just about every code
>> base, if it cannot attract new developers, it stagnates and eventually
>> whithers away.
>>
>> To attract new developers, GCC needs to modernize its internal
>> structure.  I have some thoughts on that, but progress has been slow,
>> due mostly to resource constraints.
>
> Would you mind expanding--even just a little bit--on what bits need
> modernizing?

Sure, I commented on this a bit on the dragonegg thread (things we'd
like to borrow from LLVM).

In general, I would like to continue the separation of the various
modules in the pipeline.  In particular:

- Firm APIs: remove global state, add public interfaces.
- Split up the gcc/ directory.  Move major components into libraries
(e.g, libgimple, librtl, libgeneric).
- Make each library a standalone module, with separate testsuites.
- Add unit tests for each library.
- Make all the major IRs streamable so that do things like remove the
current gty-based pch generation, or allow testing of individual
passes.
- Remove the macro-based back end configuration.  Convert it to
registered callbacks.  Allow backends to be compiled into a separate
library that can be loaded at runtime.

The theme is modularization at the library level so that we can
build/test these components separately.  The driver could simply be
dynamically linked to all of them.


> http://gcc.gnu.org/wiki/Speedup_areas
>
> and perhaps:
>
> http://gcc.gnu.org/wiki/general_backend_cleanup

Those too, yes.

> I know there are ugly parts still remaining in GCC.  But my experience
> (extending/parameterizing an LLVM optimization pass, writing/modifying
> GCC middle-end optimization passes, some GCC backend hacking) suggests
> that the complexity is similar.  I think concrete "I tried X and it
> sucked" or "these are the areas of suckage" would be helpful.

My ulterior motive for all this modularization is to extend Tom
Tromey's incremental compiler.  But I also think that it has other
benefits, mostly in testing and maintenance.

I've been collecting thoughts in this area for a few weeks.  I will
try to get it finished and publish it on the wiki.  Hopefully, soon.


Diego.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Richard Guenther]

On Wed, Apr 14, 2010 at 5:57 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Wed, Apr 14, 2010 at 11:44, Nathan Froyd <froydnj@codesourcery.com> wrote:
>> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
>>> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
>>> <lopezibanez@gmail.com> wrote:
>>> > Otherwise, as Ian said in another topic [2]: "I have a different fear:
>>> > that gcc will become increasing irrelevant".
>>>
>>> That's my impression, as well.  It is true of just about every code
>>> base, if it cannot attract new developers, it stagnates and eventually
>>> whithers away.
>>>
>>> To attract new developers, GCC needs to modernize its internal
>>> structure.  I have some thoughts on that, but progress has been slow,
>>> due mostly to resource constraints.
>>
>> Would you mind expanding--even just a little bit--on what bits need
>> modernizing?
>
> Sure, I commented on this a bit on the dragonegg thread (things we'd
> like to borrow from LLVM).
>
> In general, I would like to continue the separation of the various
> modules in the pipeline.  In particular:
>
> - Firm APIs: remove global state, add public interfaces.
> - Split up the gcc/ directory.  Move major components into libraries
> (e.g, libgimple, librtl, libgeneric).
> - Make each library a standalone module, with separate testsuites.
> - Add unit tests for each library.
> - Make all the major IRs streamable so that do things like remove the
> current gty-based pch generation, or allow testing of individual
> passes.
> - Remove the macro-based back end configuration.  Convert it to
> registered callbacks.  Allow backends to be compiled into a separate
> library that can be loaded at runtime.

Yeah, but that's all pie-in-the-sky stuff.  We first have to really properly
separate the frontends from middle-end - like solve the debug info
issue with LTO.  Like drive the whole compilation by the pass manager,
not jump into/outof it all the time.

But yes, moving the C frontend to a subdirectory was planned for a
long time.  I'm not sure about the rest - too much modularization
can hurt as much as bring benefit.  There is lots of generic infrastructure
stuff that lurks around in tree-ssa-*.c optimizers (like all the fold_gimple
stuff in tree-ssa-ccp.c that I long wanted to move to a gimple-fold.c ...).

> The theme is modularization at the library level so that we can
> build/test these components separately.  The driver could simply be
> dynamically linked to all of them.

Well, maybe nice to have, but not really the theme of GCC, and not
the most important cleanup areas.  Unit-testing is a major missing
feature, but at least for optimizers we could easily implement a
poor-mans solution using the C frontend, -O0 and single enabled
passes (given a slightly more clever pass manager).

Richard.

>
>> http://gcc.gnu.org/wiki/Speedup_areas
>>
>> and perhaps:
>>
>> http://gcc.gnu.org/wiki/general_backend_cleanup
>
> Those too, yes.
>
>> I know there are ugly parts still remaining in GCC.  But my experience
>> (extending/parameterizing an LLVM optimization pass, writing/modifying
>> GCC middle-end optimization passes, some GCC backend hacking) suggests
>> that the complexity is similar.  I think concrete "I tried X and it
>> sucked" or "these are the areas of suckage" would be helpful.
>
> My ulterior motive for all this modularization is to extend Tom
> Tromey's incremental compiler.  But I also think that it has other
> benefits, mostly in testing and maintenance.
>
> I've been collecting thoughts in this area for a few weeks.  I will
> try to get it finished and publish it on the wiki.  Hopefully, soon.
>
>
> Diego.
>

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Toon Moene]

Nathan Froyd wrote:

> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:

>> To attract new developers, GCC needs to modernize its internal
>> structure.  I have some thoughts on that, but progress has been slow,
>> due mostly to resource constraints.
> 
> Would you mind expanding--even just a little bit--on what bits need
> modernizing?  There's things like:

That's the wrong red herring :-)

Diego is afraid that GCC can't attract new developers - and he 
subsequently blames it on its bad structure.

I have seen this argument before.  It is bandied about by the Weather 
Forecasting Project I'm a researcher for: "We can't interest the 
academic world to help us because our code is incomprehensible !"

But, what happens is a combination of the following factors:

1. Academics have to plead to get our code and sign a contract never
    to use it for actual weather forecasting.

2. There is a well known US Weather Forecasting model (WRF, pronounce:
    WARF) that you can just download, comes with extensive documentation
    and an enormous user base, user support by users, etc., because of
    this.

So my solution to the Weather Forecasting model development problem 
would be: Let academia use WRF, we read their publications and decide 
which ideas to implement in our own model (instead of running around 
like headless chickens claiming that no-one wants to work with our 
model).  We have enough paid people (in 25-odd national weather services 
in Europe) to work on our model.

Mutatis mutandis, the same goes for GCC: There might be too many hurdles 
to use GCC in academia.  So what - the number of companies working on 
GCC have enough clout to employ the necessary base of engineers to keep 
GCC going (and, for an extra bonus - they do not have to invest in 
Fortran, because that's run by volunteers :-)

Case closed.

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Tom Tromey]

>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:

Richard> I think we have made good progress with cleaning up the
Richard> frontend - backend interface.

FWIW, I can attest to this based on my experience on the incremental
branch.

Tom

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Ian Lance Taylor]

Nathan Froyd <froydnj@codesourcery.com> writes:

> On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
>
>> To attract new developers, GCC needs to modernize its internal
>> structure.  I have some thoughts on that, but progress has been slow,
>> due mostly to resource constraints.
>
> Would you mind expanding--even just a little bit--on what bits need
> modernizing?

The tree/GIMPLE layer needs significantly better documentation, but is
otherwise not too bad.

Once you get to the RTL layer, there are too many undocumented
inter-pass dependencies.

The interface between the frontend and the middle-end is largely
undocumented.

Ian

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Basile Starynkevitch]

Toon Moene wrote:
> 
> Mutatis mutandis, the same goes for GCC: There might be too many hurdles 
> to use GCC in academia.  

This is probably true, however, the plugin ability of the just released 
GCC 4.5 (or is it released tomorrow) helps probably significantly.

Academics (even people working in technological research institutes like 
me) will probably be more able to practically contribute to GCC thru the 
plugin interface. It brings two minor points: a somehow defined plugin 
API (which is a sane "bottleneck" to the enormity of GCC code), and the 
ability to practically publish code without transfering copyright to FSF 
(in the previous situation, the only way to avoid that was to create a 
specific GPLv3 fork of GCC; in practice it is too expensive in labor for 
academia).

My point is that academics can quite easily contribute to GPL software, 
but much harder obtain the necessary legal authorizations to transfer 
copyright to FSF. My intuition is that if (in a different past & a 
different world which did not happen) GCC was only GPLv2+ without the 
FSF copyright requirement -exactly as Linux kernel is, things would have 
been much different.

With the new plugin ability of GCC, I would believe that academics would 
be a little happier to contribute to GCC, by coding plugins (or even 
perhaps MELT extensions, which are plugins with a different API).

I know several French university employees (professors or lecturers = 
"maitres de conférence" or interns or PhD students) who all can very 
easily, without even asking officially any high-level suit at their 
Univerisiy, publish some GPL code on their site and a paper in a 
conference or journal, but for whom getting any kind of document signed 
by their dean about transferring copyright to FSF is so painful that 
they won't even try.

I would actually believe that the amount of code from academics in the 
Linux kernel is bigger than the acedemic code in GCC, just because of 
this copyright issue (which is soften by the plugin feature, assuming 
people will publish & maintain plugin code).

Perhaps most of the GCC community don't care about getting more 
academics contribute to GCC (in my opinion this is a mistake of the GCC 
community; we should attract more academics).

Cheers.

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

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Toon Moene]

Basile Starynkevitch wrote:

> Toon Moene wrote:
>>
>> Mutatis mutandis, the same goes for GCC: There might be too many 
>> hurdles to use GCC in academia.  

> This is probably true, however, the plugin ability of the just released 
> GCC 4.5 (or is it released tomorrow) helps probably significantly.

> My point is that academics can quite easily contribute to GPL software, 
> but much harder obtain the necessary legal authorizations to transfer 
> copyright to FSF.

Nods ....

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Toon Moene]

Basile Starynkevitch wrote:

> Toon Moene wrote:
>>
>> Mutatis mutandis, the same goes for GCC: There might be too many 
>> hurdles to use GCC in academia.  
> 
> This is probably true, however, the plugin ability of the just released 
> GCC 4.5 (or is it released tomorrow) helps probably significantly.

> My point is that academics can quite easily contribute to GPL software, 
> but much harder obtain the necessary legal authorizations to transfer 
> copyright to FSF. 

My answer was not as clear as necessary.  My (earlier) argument was from 
the perspective of the providers of the code (GCC) - it did not take 
into account those who *want* to contribute to GCC, but have a hard time 
to convince their respective legal departments (whether in academia or 
the commercial world).

In that case, a clear plugin interface (and accompanying documentation) 
can be instrumental in proving that an improvement "actually does the 
desired thing" and hence can be considered "the outcome of the academic 
research" (which then subsequently can be written up in a paper).

Thanks for pointing that out.

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> My point is that academics can quite easily contribute to GPL
> software, but much harder obtain the necessary legal authorizations to
> transfer copyright to FSF. My intuition is that if (in a different
> past & a different world which did not happen) GCC was only GPLv2+
> without the FSF copyright requirement -exactly as Linux kernel is,
> things would have been much different.

That is likely true, but it's something that we really don't want to
change.  The FSF could and should make the copyright disclaimer much
simpler--for example, you can do Google's copyright disclaimer on a
web page (http://code.google.com/legal/individual-cla-v1.0.html).  But
avoiding the copyright disclaimer entirely is what permitted, e.g.,
the SCO debacle to occur.

Ian

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Nathan Froyd]

On Wed, Apr 14, 2010 at 09:49:08PM +0200, Basile Starynkevitch wrote:
> Toon Moene wrote:
>>
>> Mutatis mutandis, the same goes for GCC: There might be too many 
>> hurdles to use GCC in academia.  
>
> This is probably true, however, the plugin ability of the just released  
> GCC 4.5 (or is it released tomorrow) helps probably significantly.
>
> Academics (even people working in technological research institutes like  
> me) will probably be more able to practically contribute to GCC thru the  
> plugin interface. It brings two minor points: a somehow defined plugin  
> API (which is a sane "bottleneck" to the enormity of GCC code), and the  
> ability to practically publish code without transfering copyright to FSF  
> (in the previous situation, the only way to avoid that was to create a  
> specific GPLv3 fork of GCC; in practice it is too expensive in labor for  
> academia).

I appreciate the point about the difficulty of copyright transference in
an academic environment, having gone through such difficulties myself.
But I think you are confusing "using GCC as a base for your research
activities" and "getting the results of that research accepted
upstream".  I think plugins help in the first category insofar as they
force GCC to clearly define interface boundaries.  But they have little
effect concerning the second category.

Perhaps people will be able to make their code more widely available:
the plugin interface will likely be relatively stable (I realize this is
not guaranteed) and people can therefore release easily compilable
packages.  Before, you would be forced to distribute (and maintain!)
patch files that may need significant changes from release to release.

-Nathan

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

On 14 April 2010 22:46, Ian Lance Taylor <iant@google.com> wrote:
> Basile Starynkevitch <basile@starynkevitch.net> writes:
>
>> My point is that academics can quite easily contribute to GPL
>> software, but much harder obtain the necessary legal authorizations to
>> transfer copyright to FSF. My intuition is that if (in a different
>> past & a different world which did not happen) GCC was only GPLv2+
>> without the FSF copyright requirement -exactly as Linux kernel is,
>> things would have been much different.
>
> That is likely true, but it's something that we really don't want to
> change.  The FSF could and should make the copyright disclaimer much
> simpler--for example, you can do Google's copyright disclaimer on a
> web page (http://code.google.com/legal/individual-cla-v1.0.html).  But
> avoiding the copyright disclaimer entirely is what permitted, e.g.,
> the SCO debacle to occur.

Have you suggested this to the FSF with this specific example? The
Google's disclaimer is in fact much more complex that the FSF's one I
received, so doing it via web would be even simpler/easier.

And in fact, GCC will be better served if the FSF produced a copyright
disclaimer specific for GCC, because the first one I received was too
vague and general for my university to accept, once it was made more
specific, the university had no problem to sign it.

Could not the Steering Committee ask the FSF to make some progress on this?

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Basile Starynkevitch]

Ian Lance Taylor wrote:
> Basile Starynkevitch <basile@starynkevitch.net> writes:
> 
>> My point is that academics can quite easily contribute to GPL
>> software, but much harder obtain the necessary legal authorizations to
>> transfer copyright to FSF. My intuition is that if (in a different
>> past & a different world which did not happen) GCC was only GPLv2+
>> without the FSF copyright requirement -exactly as Linux kernel is,
>> things would have been much different.
> 
> That is likely true, but it's something that we really don't want to
> change.  The FSF could and should make the copyright disclaimer much
> simpler--for example, you can do Google's copyright disclaimer on a
> web page (http://code.google.com/legal/individual-cla-v1.0.html).  But
> avoiding the copyright disclaimer entirely is what permitted, e.g.,
> the SCO debacle to occur.


 From what I understood of the runtime exception of GCC, plugins should 
be GPLv3 licensed but are not requested to be FSF copyrighted. Of course 
such plugin code is not inside GCC FSF (I am expecting it would be 
hosted elsewhere, e.g. on some university site; of course FSF owned 
plugins -like MELT- are different).

 From the point of view of an academic, that makes a significant 
difference. And even if he/she want to push code inside GCC (and for 
that he still will need the transfer to FSF, unless GCC changes a lot), 
convincing his big boss to sign a paper is less terrible when you 
actually have some code (in a plugin form) that really has some outside 
interest. In that (optimistic) situation, the academic could spend some 
of his time to get the legal papers signed.

Before the plugins, the academics could fork GCC (a huge non academic 
task) and work on his fork (practically unlikely) or should take the 
effort to get the legal papers signed before coding the first line of 
code (very hard, and very discouraging).

A university (or research institute) boss in big suit [able to sign 
legal papers] is probably more keen to sign a legal paper with the FSF 
once some code -from his university- exist which attracts outside 
interest, and not before.

And my personal preference on GCC licensing would be more a Linux-kernel 
like GPL with copyright belonging to authors employee (I don't feel a 
SCO like issue as a major threat today; it might have been ten years 
ago). That is much easier to get than a copyright transfer to FSF.

And GCC is probably less threatened today by legal issues à la SCO than 
by obesity, obsolescence, outside competition -eg LLVM- and perhaps even 
less interest by industry for the low level languages (C, C++, Ada) GCC 
is processing. Even in industry, scripting languages (or languages like 
Java or C# which are not practically significant for GCC) have more 
market share than a dozen years ago.

Cheers.

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

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

On 14 April 2010 23:34, Basile Starynkevitch <basile@starynkevitch.net> wrote:
>
> And my personal preference on GCC licensing would be more a Linux-kernel
> like GPL with copyright belonging to authors employee (I don't feel a SCO
> like issue as a major threat today; it might have been ten years ago). That
> is much easier to get than a copyright transfer to FSF.

I am sorry but I do not think the copyright transfer/ GCC license is
worth discussing in this list. What we can improve (and we should) is
the process itself to simplify contribution but the legal aspects and
discussions about licenses are off-topic in this list and likely to
generate more noise than productive results. In any case, if you or
your legal department think they help in this area, you should please
get in contact directly with the legal department of the FSF. There is
nothing we can do in this list.

And given the feedback provided by Grigori, the licensing issues are
very low in the list of complains from academia and the major
complaints are technical (speed, simplicity, and documentation).

> And GCC is probably less threatened today by legal issues ą la SCO than by
> obesity, obsolescence, outside competition -eg LLVM- and perhaps even less
> interest by industry for the low level languages (C, C++, Ada) GCC is
> processing. Even in industry, scripting languages (or languages like Java or
> C# which are not practically significant for GCC) have more market share
> than a dozen years ago.

You know there is a Java FE in GCC, don't you?

http://gcc.gnu.org/java/

And whether a language is significant or not for GCC is a question of
someone contributing a FE for it. So if someone wants to generate
optimized machine code for a large number of targets from their C#
source code, they are welcome to contribute a C# FE.

And calling Ada "low-level"... Honestly, let's stop this sub-thread
here. No more discussion about plugins or legal issues, please.

Cheers,

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

I would like to give my opinion as a volunteer contributor on several
of the points you raised.

On 14 April 2010 16:23, Grigori Fursin <gfursin@gmail.com> wrote:
>
> * Need to encourage cleanup/infrastructure work on GCC and provide
> stable/flexible/extensible APIs (the question is how to encourage such
> infrastructure work...?)

I think by:

1) Asking for it in precise terms in the gcc@ list. What exactly you
want to achieve? How would you suggest to achieve it? If you ask for
small changes, there is high chance that someone will do it for you
for free.

2) Otherwise, providing patches! Honestly, if you find that something
can be made more moduler/flexible/extensible, provide a patch and if
you are right there is a high chance it will be committed.

3) For large changes, creating a project, a public gcc branch,
attracting some developers and getting it done. Then commit it to GCC
trunk.

> * Open up GCC to be used as a library by other tools, so that other tools
> could use its analysis facilities. For example, having alias analysis as an
> API rather than a pass that needs to be applied and then collect
> information. Allow developers/tools access those functions outside GCC
> (should be a high-level API).

For this to get done, people that are going to use it should first get
together and define such API and its requirements. That would be the
first step! Do this, by discussing it in the gcc@ list. Do not define
it on your own and just drop it on us (and on other potential users).
That is never going to work.

The next step would be to implement it. The smaller the changes, the
easier to get them merged. So provide small self-contained and
"useful" patches, not a huge patch that implements everything in one
go. That won't work either.

> * Follow up to the above: Need to come up with a common API /
> standardization / common levels of abstractions. Decide on how to
> coordinate efforts and find commonalities.

Good! Again, the keys are "API discussion in gcc@" and "small patches".

> * Need a simple pass manager that can list all available passes
> and allow any scheduling (providing dependency information).

I think GCC will love to have this. So if someone contributes this in
the "proper" way, it will be eagerly accepted.

> * Make more visible/accessible guides for building/extending GCC.

Again, we will love to have this but we need people to do it. Another
point: I think it is more likely that GCC developers would answer in
this list all questions necessary to build such guides than to sit
down and actually write them. So the problem is not to get the
knowledge but that someone puts the effort to write it down in an
organised manner.

If such guides were available, we will be happy to link/host them in
GCC servers.

> * Better advertize Google Summer of Code, and provide more mentoring.

How could we advertise it better?

Another idea could be that researchers and academia encourage students
to work/extend GCC. If, like in the Google Summer of Code, the work is
useful for GCC, I have the feeling that GCC developers would be happy
to mentor (o co-mentor together with the academic advisor of the
student). Moreover, GCC developers can assess whether a project is
feasible or not in a particular time limit. Something that students
and their advisor are likely to get wrong.

Can you reach the adequate audience and transmit these ideas?

> * GCC tries to auto-parallelize the programs it compiles. Will GCC itself
> be made more multi-threaded and run faster in a multi-core environment...?

Even if GCC wouldn't benefit from being multi-threaded, which I don't
know whether it is true, the work to make it more "thread-safe" is
likely to be beneficial for modularity and cleanliness. So, again, I
don't think GCC developers are against this. On the contrary! We will
love it. But someone has to sit down and identify the problems and
start submitting patches. For sure, if you state explicitly what you
want to do, GCC developers can point out what would be needed for
achieving that.

> We hope these notes would help improve GCC and its appeal/usability for
> researches (or at least raise more discussion!)

I think they are interesting but it mostly boils down to "be precise",
"get involved" and "patches are welcome".

Cheers,

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Basile Starynkevitch]

On Thu, Apr 15, 2010 at 10:26:16AM +0200, Manuel López-Ibáñez wrote:
> On 14 April 2010 23:34, Basile Starynkevitch <basile@starynkevitch.net> wrote:
> >
> > And my personal preference on GCC licensing would be more a Linux-kernel
> > like GPL with copyright belonging to authors employee (I don't feel a SCO
> > like issue as a major threat today; it might have been ten years ago). That
> > is much easier to get than a copyright transfer to FSF.
> 
> I am sorry but I do not think the copyright transfer/ GCC license is
> worth discussing in this list. 

Then sorry for having discussed it. It was only my personal option.
Discussion closed.

> 
> And given the feedback provided by Grigori, the licensing issues are
> very low in the list of complains from academia and the major
> complaints are technical (speed, simplicity, and documentation).
> 
> > And GCC is probably less threatened today by legal issues Ä… la SCO than by
> > obesity, obsolescence, outside competition -eg LLVM- and perhaps even less
> > interest by industry for the low level languages (C, C++, Ada) GCC is
> > processing. Even in industry, scripting languages (or languages like Java or
> > C# which are not practically significant for GCC) have more market share
> > than a dozen years ago.
> 
> You know there is a Java FE in GCC, don't you?


Of course I do know about gcj. But I never met any person using it, and I
don't know about any person or project really using it (as an example, I am
not sure than any Debian or Fedora package is compiled with gcj into a
native executable; do you know of many Debian packages compiled with GCJ
specifically?). But I don't know much about Java (except practically Sun's
JVM, IBM's one, and OpenJdk).

> 
> And whether a language is significant or not for GCC is a question of
> someone contributing a FE for it. 

I did not meant significant for GCC, I did meant significant for industrial
use (outside of the GCC community). What I just believe is that programming
languages usually compiled by GCC are a bit less used than ten years ago (in
favor of scripting languages such as PHP). And it is the industrial
importance of languages which I believe determine indirectly the work on GCC
(because industrials are funding directly or indirectly, or at least are
lobbying for, most of the labor put into GCC)

> And calling Ada "low-level"... Honestly, let's stop this sub-thread
> here. No more discussion about plugins or legal issues, please.


Ok. Sorry for the inconvenience.

(BTW I call lowlevel any language which does not manage memory
automatically; I am quite fond of Ocaml even if I don't use it much today.
So in my eyes C++, Ada95 & Fortran2005 are still low-level; this is only a
matter of taste & terminology).

Cheers

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

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Andrew Haley]

On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
> 
> Of course I do know about gcj. But I never met any person using it,
> and I don't know about any person or project really using it (as an
> example, I am not sure than any Debian or Fedora package is compiled
> with gcj into a native executable; do you know of many Debian
> packages compiled with GCJ specifically?).

Lots of them were, but with the availability of OpenJDK and its better
standard compatibility people are moving packages to it.  There's
nothing much wrong with the gcj compiler itself, although it does
generate rather bulky code, but the Classpath libraries on which its
runtime library depends are not completely Java compatible.

Andrew.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Steven Bosscher]

On Thu, Apr 15, 2010 at 2:03 PM, Andrew Haley <aph@redhat.com> wrote:
> On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
>>
>> Of course I do know about gcj. But I never met any person using it,
>> and I don't know about any person or project really using it (as an
>> example, I am not sure than any Debian or Fedora package is compiled
>> with gcj into a native executable; do you know of many Debian
>> packages compiled with GCJ specifically?).
>
> Lots of them were, but with the availability of OpenJDK and its better
> standard compatibility people are moving packages to it.  There's
> nothing much wrong with the gcj compiler itself, although it does
> generate rather bulky code, but the Classpath libraries on which its
> runtime library depends are not completely Java compatible.

So our computers are spending hours and hours testing Java as part of
the normal bootstrap+regtest cycle -- and nobody even uses it? :-)

(Couldn't resist, sorry! :-)

Ciao!
Steven

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Andrew Haley]

On 04/15/2010 01:07 PM, Steven Bosscher wrote:
> On Thu, Apr 15, 2010 at 2:03 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
>>>
>>> Of course I do know about gcj. But I never met any person using it,
>>> and I don't know about any person or project really using it (as an
>>> example, I am not sure than any Debian or Fedora package is compiled
>>> with gcj into a native executable; do you know of many Debian
>>> packages compiled with GCJ specifically?).
>>
>> Lots of them were, but with the availability of OpenJDK and its better
>> standard compatibility people are moving packages to it.  There's
>> nothing much wrong with the gcj compiler itself, although it does
>> generate rather bulky code, but the Classpath libraries on which its
>> runtime library depends are not completely Java compatible.
> 
> So our computers are spending hours and hours testing Java as part of
> the normal bootstrap+regtest cycle -- and nobody even uses it? :-)
> 
> (Couldn't resist, sorry! :-)

Fair enough, have your joke, but that's not what I wrote!

And BTW, these days many (most?) of the bugs the gcj test suite finds
are bug in gcc that the other test suites didn't find.

And BTBTW, I would love to find time to use the OpenJDK library in
gcj.  gcj is still AFAIK the most portable implementation of the Java
language.

Andrew.

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Dear Manuel,

Thank you very much for your answers! This is what I believe researchers 
who are trying to select a compiler for their work would like to know/hear.

I think, the main problem for students and researchers is that they
see lots of stuff going on with GCC and on mailing lists but they may
be shy/scared/not sure where to start if they want to contribute
or even if they will be welcome to contribute. The reason is that
some of their ideas/work may not be necessarily immediately useful to the community
and they may be concerned that they can get lots of aggressive, negative feedback
due to that. Of course, this can be also understandable, since many of you on this 
list do an extremely hard and time-consuming work to support/update GCC and some 
novel/fancy/long-term ideas may be really distractive from the current GCC agenda 
no matter how useful they are in the future. However, such feedback can immediately 
drive away young and motivated students who can otherwise become really active 
contributors (look at the GRAPHITE and students contributing to GCC now, for example).

So, what I think could be useful, is to try to agree on what can be
some general common suggestions/recommendations to students/researchers 
who may want to contribute but not sure how to approach GCC community.
Maybe we can make a page on GCC Wiki with such recommendations or even
maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
ideas so that only those of you who are interested in that can follow/discuss them
and from time to time approach this mailing list with already mature ideas
to avoid bothering others who are distracted by such discussions on this mailing list?
Maybe it will help to avoid long, repetitive discussions and occasional sad accusations 
on this technical mailing list?..

Actually, maybe this can be an interesting topic for discussion at the next
GCC Summit and GROW'11?.. 

Also, I think that the modularity and stable API of the compiler would generally
simplify this issue since it would allow much more non-intrusive modifications but
I understand that it's not easy to do now without collaborative agreement and
development, and that there is some gradual movement in that direction anyway...

By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
mailing list?

Thanks again!!!
Grigori

> * Need to encourage cleanup/infrastructure work on GCC and provide
> stable/flexible/extensible APIs (the question is how to encourage such
> infrastructure work...?)

I think by:

1) Asking for it in precise terms in the gcc@ list. What exactly you
want to achieve? How would you suggest to achieve it? If you ask for
small changes, there is high chance that someone will do it for you
for free.

2) Otherwise, providing patches! Honestly, if you find that something
can be made more moduler/flexible/extensible, provide a patch and if
you are right there is a high chance it will be committed.

3) For large changes, creating a project, a public gcc branch,
attracting some developers and getting it done. Then commit it to GCC
trunk.

> * Open up GCC to be used as a library by other tools, so that other tools
> could use its analysis facilities. For example, having alias analysis as an
> API rather than a pass that needs to be applied and then collect
> information. Allow developers/tools access those functions outside GCC
> (should be a high-level API).

For this to get done, people that are going to use it should first get
together and define such API and its requirements. That would be the
first step! Do this, by discussing it in the gcc@ list. Do not define
it on your own and just drop it on us (and on other potential users).
That is never going to work.

The next step would be to implement it. The smaller the changes, the
easier to get them merged. So provide small self-contained and
"useful" patches, not a huge patch that implements everything in one
go. That won't work either.

> * Follow up to the above: Need to come up with a common API /
> standardization / common levels of abstractions. Decide on how to
> coordinate efforts and find commonalities.

Good! Again, the keys are "API discussion in gcc@" and "small patches".

> * Need a simple pass manager that can list all available passes
> and allow any scheduling (providing dependency information).

I think GCC will love to have this. So if someone contributes this in
the "proper" way, it will be eagerly accepted.

> * Make more visible/accessible guides for building/extending GCC.

Again, we will love to have this but we need people to do it. Another
point: I think it is more likely that GCC developers would answer in
this list all questions necessary to build such guides than to sit
down and actually write them. So the problem is not to get the
knowledge but that someone puts the effort to write it down in an
organised manner.

If such guides were available, we will be happy to link/host them in
GCC servers.

> * Better advertize Google Summer of Code, and provide more mentoring.

How could we advertise it better?

Another idea could be that researchers and academia encourage students
to work/extend GCC. If, like in the Google Summer of Code, the work is
useful for GCC, I have the feeling that GCC developers would be happy
to mentor (o co-mentor together with the academic advisor of the
student). Moreover, GCC developers can assess whether a project is
feasible or not in a particular time limit. Something that students
and their advisor are likely to get wrong.

Can you reach the adequate audience and transmit these ideas?

> * GCC tries to auto-parallelize the programs it compiles. Will GCC itself
> be made more multi-threaded and run faster in a multi-core environment...?

Even if GCC wouldn't benefit from being multi-threaded, which I don't
know whether it is true, the work to make it more "thread-safe" is
likely to be beneficial for modularity and cleanliness. So, again, I
don't think GCC developers are against this. On the contrary! We will
love it. But someone has to sit down and identify the problems and
start submitting patches. For sure, if you state explicitly what you
want to do, GCC developers can point out what would be needed for
achieving that.

> We hope these notes would help improve GCC and its appeal/usability for
> researches (or at least raise more discussion!)

I think they are interesting but it mostly boils down to "be precise",
"get involved" and "patches are welcome".

Cheers,

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

On 16 April 2010 13:21, Grigori Fursin <gfursin@gmail.com> wrote:
>
> I think, the main problem for students and researchers is that they
> see lots of stuff going on with GCC and on mailing lists but they may
> be shy/scared/not sure where to start if they want to contribute
> or even if they will be welcome to contribute. The reason is that
> some of their ideas/work may not be necessarily immediately useful to the community
> and they may be concerned that they can get lots of aggressive, negative feedback

That is why mentoring could be helpful. Technical discussions by email
sometimes appear harsh and dry to newcomers. Moreover, negative
opinions are more vocal than positive ones. So something that most
people think is a good idea or they are indifferent may only get
negative feedback from a few.

> no matter how useful they are in the future. However, such feedback can immediately
> drive away young and motivated students who can otherwise become really active
> contributors (look at the GRAPHITE and students contributing to GCC now, for example).
>
> So, what I think could be useful, is to try to agree on what can be
> some general common suggestions/recommendations to students/researchers

A short list out of the top of my head for proposing ideas in gcc mailing lists:

* If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping what they are doing to
help you. Volunteers have very very limited time and paid developers
are paid to do something else. In fact, asking GCC developers to do
anything for you, no matter how trivial it seems to you, will likely
result in negative feedback. Probably it is no trivial at all.

* if your idea may potentially slow down the compiler, increase memory
consumption, increase complexity, remove features, or change defaults,
it will receive negative feedback. Guaranteed. If you are sure that
this is not the case or that  the benefits outweigh the drawbacks, but
GCC developers disagree, discussion is not going to solve it. The only
way is to implement your idea (or a working prototype) and give
substantial experimental evidence in many scenarios/targets that you
are right.

* If you have a great idea implemented and provide a substantial
patch, expect negative feedback. There are many ongoing projects in
GCC. A patch that comes out of the blue and breaks those projects will
not be welcome by the people working on those projects.

* Your email/patch may not receive much feedback. This may happen if
you provide your idea in an old thread (people stop reading long
threads after a while), your subject line was not
interesting/descriptive enough (I do not read all emails from the
list), the main audience of your email just missed/overlooked it by
chance (bad luck, busy period, vacations), your email was too long
(people stopped reading before reaching the interesting part), ... The
only feasible choice is to try again sometime later with an improved
message.

* There is also the IRC channels (http://gcc.gnu.org/wiki), which are
more interactive, but the same rules apply to them. Specially being
ignored despite people talking to each other. That is because people
are working, and sometimes they have deadlines, urgent stuff to do,
they want to go home early...

* Read the gcc and the gcc-patches lists for a while to get to know
how things work and who is who.

I am sure there are many more little rules-of-thumb I can come up with.

> who may want to contribute but not sure how to approach GCC community.
> Maybe we can make a page on GCC Wiki with such recommendations or even

Anyone can edit the wiki, so be my guest.

> maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
> ideas so that only those of you who are interested in that can follow/discuss them
> and from time to time approach this mailing list with already mature ideas
> to avoid bothering others who are distracted by such discussions on this mailing list?

An example of how *not* to get things done is this "maybe we"
attitude. It is likely to get no feedback, negative feedback, or
positive feedback that sounds a bit negative (like my "be my guest"
above for the wiki page):

* It does not specify who is "we". It could be understood as asking
the reader to do something that takes time and effort. Everybody is
busy already, so bad strategy. It can also be understood as only you
or people that you know already that are going to do it. So the reader
understands that he/she does not need to do anything and just wait for
you. Hence, if you were expecting feedback/action, you will be
disappointed.

* "maybe" is vague. Vague ideas are ignored or criticized because
either there are not enough details to have an opinion or it is easy
to misunderstand them.

For example, a better way to move the above idea forward would be:

1) Send a new email with a descriptive subject "A new gcc mailing list
for experimenting with gcc"

2) Say: "I would like to create a new mailing list gcc-experimental
for this and that. I know so many people that are already interested
to join. I would like to create it in the gcc servers. Who is
responsible for creating a new mailing list? (If overwhelming negative
feedback from the responsible then a further email) "OK, no problem. I
created the mailing list in google groups, this is a patch to add a
link to it in the GCC webpages." (let's assume that you still get very
negative feedback from the responsible of the webpages) "Oh, I see. I
understand your concerns, I will add a link to it from the wiki page.
Anyone interested is welcome to join. Thanks! :-D"

3) Expect some negative feedback, some bike-shedding "I prefer the
name gcc-crazy-ideas". And bear in mind that you only need to make the
changes that are asked by the decision makers for your problem, in
this case, the people with the power to create the mailing list,
approve patches to the webpages. If those people are in favour, it
doesn't matter who is against it (Of course, it many people are
against it, then the responsible may change their mind, but it also
work the other way around, so pleasing people may help to change the
opinion of the responsibles.)

> By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
> mailing list?

You may forward it, quote parts or edit it for your purposes, with or
without attribution. I hereby donate it to the public domain ;-)

Cheers,

Manuel.

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Thanks again, Manuel! 

I really appreciate your detailed thoughts and I think they will be really 
very useful to the new-comers. By the way, I agree with them and I was just 
still trying to pass the message from the participants of the GROW workshop 
but I think that now things should be much more clear. 

I will try to create this page on GCC Wiki this weekend so that if new 
students/researchers try to approach GCC community without reading that, 
they can be gently pointed out to this page that can avoid offences and 
mis-interpretation. I hope that my colleagues will help
to update this page later since I changed the job a few months ago and
my work is for now orthogonal/not directly related to GCC so I can only 
do it in my spare time but I still hope it will be useful ...

Cheers,
Grigori

-----Original Message-----
From: Manuel López-Ibáñez [mailto:lopezibanez@gmail.com] 
Sent: Friday, April 16, 2010 6:51 PM
To: Grigori Fursin
Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.rohou@inria.fr; David Edelsohn
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On 16 April 2010 13:21, Grigori Fursin <gfursin@gmail.com> wrote:
>
> I think, the main problem for students and researchers is that they
> see lots of stuff going on with GCC and on mailing lists but they may
> be shy/scared/not sure where to start if they want to contribute
> or even if they will be welcome to contribute. The reason is that
> some of their ideas/work may not be necessarily immediately useful to the community
> and they may be concerned that they can get lots of aggressive, negative feedback

That is why mentoring could be helpful. Technical discussions by email
sometimes appear harsh and dry to newcomers. Moreover, negative
opinions are more vocal than positive ones. So something that most
people think is a good idea or they are indifferent may only get
negative feedback from a few.

> no matter how useful they are in the future. However, such feedback can immediately
> drive away young and motivated students who can otherwise become really active
> contributors (look at the GRAPHITE and students contributing to GCC now, for example).
>
> So, what I think could be useful, is to try to agree on what can be
> some general common suggestions/recommendations to students/researchers

A short list out of the top of my head for proposing ideas in gcc mailing lists:

* If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping what they are doing to
help you. Volunteers have very very limited time and paid developers
are paid to do something else. In fact, asking GCC developers to do
anything for you, no matter how trivial it seems to you, will likely
result in negative feedback. Probably it is no trivial at all.

* if your idea may potentially slow down the compiler, increase memory
consumption, increase complexity, remove features, or change defaults,
it will receive negative feedback. Guaranteed. If you are sure that
this is not the case or that  the benefits outweigh the drawbacks, but
GCC developers disagree, discussion is not going to solve it. The only
way is to implement your idea (or a working prototype) and give
substantial experimental evidence in many scenarios/targets that you
are right.

* If you have a great idea implemented and provide a substantial
patch, expect negative feedback. There are many ongoing projects in
GCC. A patch that comes out of the blue and breaks those projects will
not be welcome by the people working on those projects.

* Your email/patch may not receive much feedback. This may happen if
you provide your idea in an old thread (people stop reading long
threads after a while), your subject line was not
interesting/descriptive enough (I do not read all emails from the
list), the main audience of your email just missed/overlooked it by
chance (bad luck, busy period, vacations), your email was too long
(people stopped reading before reaching the interesting part), ... The
only feasible choice is to try again sometime later with an improved
message.

* There is also the IRC channels (http://gcc.gnu.org/wiki), which are
more interactive, but the same rules apply to them. Specially being
ignored despite people talking to each other. That is because people
are working, and sometimes they have deadlines, urgent stuff to do,
they want to go home early...

* Read the gcc and the gcc-patches lists for a while to get to know
how things work and who is who.

I am sure there are many more little rules-of-thumb I can come up with.

> who may want to contribute but not sure how to approach GCC community.
> Maybe we can make a page on GCC Wiki with such recommendations or even

Anyone can edit the wiki, so be my guest.

> maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
> ideas so that only those of you who are interested in that can follow/discuss them
> and from time to time approach this mailing list with already mature ideas
> to avoid bothering others who are distracted by such discussions on this mailing list?

An example of how *not* to get things done is this "maybe we"
attitude. It is likely to get no feedback, negative feedback, or
positive feedback that sounds a bit negative (like my "be my guest"
above for the wiki page):

* It does not specify who is "we". It could be understood as asking
the reader to do something that takes time and effort. Everybody is
busy already, so bad strategy. It can also be understood as only you
or people that you know already that are going to do it. So the reader
understands that he/she does not need to do anything and just wait for
you. Hence, if you were expecting feedback/action, you will be
disappointed.

* "maybe" is vague. Vague ideas are ignored or criticized because
either there are not enough details to have an opinion or it is easy
to misunderstand them.

For example, a better way to move the above idea forward would be:

1) Send a new email with a descriptive subject "A new gcc mailing list
for experimenting with gcc"

2) Say: "I would like to create a new mailing list gcc-experimental
for this and that. I know so many people that are already interested
to join. I would like to create it in the gcc servers. Who is
responsible for creating a new mailing list? (If overwhelming negative
feedback from the responsible then a further email) "OK, no problem. I
created the mailing list in google groups, this is a patch to add a
link to it in the GCC webpages." (let's assume that you still get very
negative feedback from the responsible of the webpages) "Oh, I see. I
understand your concerns, I will add a link to it from the wiki page.
Anyone interested is welcome to join. Thanks! :-D"

3) Expect some negative feedback, some bike-shedding "I prefer the
name gcc-crazy-ideas". And bear in mind that you only need to make the
changes that are asked by the decision makers for your problem, in
this case, the people with the power to create the mailing list,
approve patches to the webpages. If those people are in favour, it
doesn't matter who is against it (Of course, it many people are
against it, then the responsible may change their mind, but it also
work the other way around, so pleasing people may help to change the
opinion of the responsibles.)

> By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
> mailing list?

You may forward it, quote parts or edit it for your purposes, with or
without attribution. I hereby donate it to the public domain ;-)

Cheers,

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Laurent GUERBY]

On Thu, 2010-04-15 at 13:57 +0200, Basile Starynkevitch wrote:
> (BTW I call lowlevel any language which does not manage memory
> automatically; I am quite fond of Ocaml even if I don't use it much today.
> So in my eyes C++, Ada95 & Fortran2005 are still low-level; this is only a
> matter of taste & terminology).

You didn't look very hard in the Ada Reference Manual :). 

Garbage collection support for Ada implementations is optional but
defined in Ada since the first standard in 1983.

All Ada standards (83/95/05) do have a "garbage collection" entry in
their index wich lists the various parts of the standard interacting
with absence or presence of automatic memory management, for example
see "pragma Controlled".

GNAT/GCC does not provide garbage collection but GNAT/dotnet and
GNAT/Java do provide it so you can run Ada software these days without
having to do manual memory management.

Sincerely,

Laurent

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Hi all,

I created the page on GCC Wiki with this info:
http://gcc.gnu.org/wiki/GCC_Research

Please, feel free to update or rewrite completely 
(if you feel that something is wrong, etc)...

Hope it will be of any use ;) ...

Cheers,
Grigori

-----Original Message-----
From: Manuel López-Ibáñez [mailto:lopezibanez@gmail.com] 
Sent: Friday, April 16, 2010 6:51 PM
To: Grigori Fursin
Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.rohou@inria.fr; David Edelsohn
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On 16 April 2010 13:21, Grigori Fursin <gfursin@gmail.com> wrote:
>
> I think, the main problem for students and researchers is that they
> see lots of stuff going on with GCC and on mailing lists but they may
> be shy/scared/not sure where to start if they want to contribute
> or even if they will be welcome to contribute. The reason is that
> some of their ideas/work may not be necessarily immediately useful to the community
> and they may be concerned that they can get lots of aggressive, negative feedback

That is why mentoring could be helpful. Technical discussions by email
sometimes appear harsh and dry to newcomers. Moreover, negative
opinions are more vocal than positive ones. So something that most
people think is a good idea or they are indifferent may only get
negative feedback from a few.

> no matter how useful they are in the future. However, such feedback can immediately
> drive away young and motivated students who can otherwise become really active
> contributors (look at the GRAPHITE and students contributing to GCC now, for example).
>
> So, what I think could be useful, is to try to agree on what can be
> some general common suggestions/recommendations to students/researchers

A short list out of the top of my head for proposing ideas in gcc mailing lists:

* If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping what they are doing to
help you. Volunteers have very very limited time and paid developers
are paid to do something else. In fact, asking GCC developers to do
anything for you, no matter how trivial it seems to you, will likely
result in negative feedback. Probably it is no trivial at all.

* if your idea may potentially slow down the compiler, increase memory
consumption, increase complexity, remove features, or change defaults,
it will receive negative feedback. Guaranteed. If you are sure that
this is not the case or that  the benefits outweigh the drawbacks, but
GCC developers disagree, discussion is not going to solve it. The only
way is to implement your idea (or a working prototype) and give
substantial experimental evidence in many scenarios/targets that you
are right.

* If you have a great idea implemented and provide a substantial
patch, expect negative feedback. There are many ongoing projects in
GCC. A patch that comes out of the blue and breaks those projects will
not be welcome by the people working on those projects.

* Your email/patch may not receive much feedback. This may happen if
you provide your idea in an old thread (people stop reading long
threads after a while), your subject line was not
interesting/descriptive enough (I do not read all emails from the
list), the main audience of your email just missed/overlooked it by
chance (bad luck, busy period, vacations), your email was too long
(people stopped reading before reaching the interesting part), ... The
only feasible choice is to try again sometime later with an improved
message.

* There is also the IRC channels (http://gcc.gnu.org/wiki), which are
more interactive, but the same rules apply to them. Specially being
ignored despite people talking to each other. That is because people
are working, and sometimes they have deadlines, urgent stuff to do,
they want to go home early...

* Read the gcc and the gcc-patches lists for a while to get to know
how things work and who is who.

I am sure there are many more little rules-of-thumb I can come up with.

> who may want to contribute but not sure how to approach GCC community.
> Maybe we can make a page on GCC Wiki with such recommendations or even

Anyone can edit the wiki, so be my guest.

> maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
> ideas so that only those of you who are interested in that can follow/discuss them
> and from time to time approach this mailing list with already mature ideas
> to avoid bothering others who are distracted by such discussions on this mailing list?

An example of how *not* to get things done is this "maybe we"
attitude. It is likely to get no feedback, negative feedback, or
positive feedback that sounds a bit negative (like my "be my guest"
above for the wiki page):

* It does not specify who is "we". It could be understood as asking
the reader to do something that takes time and effort. Everybody is
busy already, so bad strategy. It can also be understood as only you
or people that you know already that are going to do it. So the reader
understands that he/she does not need to do anything and just wait for
you. Hence, if you were expecting feedback/action, you will be
disappointed.

* "maybe" is vague. Vague ideas are ignored or criticized because
either there are not enough details to have an opinion or it is easy
to misunderstand them.

For example, a better way to move the above idea forward would be:

1) Send a new email with a descriptive subject "A new gcc mailing list
for experimenting with gcc"

2) Say: "I would like to create a new mailing list gcc-experimental
for this and that. I know so many people that are already interested
to join. I would like to create it in the gcc servers. Who is
responsible for creating a new mailing list? (If overwhelming negative
feedback from the responsible then a further email) "OK, no problem. I
created the mailing list in google groups, this is a patch to add a
link to it in the GCC webpages." (let's assume that you still get very
negative feedback from the responsible of the webpages) "Oh, I see. I
understand your concerns, I will add a link to it from the wiki page.
Anyone interested is welcome to join. Thanks! :-D"

3) Expect some negative feedback, some bike-shedding "I prefer the
name gcc-crazy-ideas". And bear in mind that you only need to make the
changes that are asked by the decision makers for your problem, in
this case, the people with the power to create the mailing list,
approve patches to the webpages. If those people are in favour, it
doesn't matter who is against it (Of course, it many people are
against it, then the responsible may change their mind, but it also
work the other way around, so pleasing people may help to change the
opinion of the responsibles.)

> By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
> mailing list?

You may forward it, quote parts or edit it for your purposes, with or
without attribution. I hereby donate it to the public domain ;-)

Cheers,

Manuel.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Manuel López-Ibáñez]

On 27 April 2010 14:27, Grigori Fursin <gfursin@gmail.com> wrote:
> Hi all,
>
> I created the page on GCC Wiki with this info:
> http://gcc.gnu.org/wiki/GCC_Research
>
> Please, feel free to update or rewrite completely
> (if you feel that something is wrong, etc)...
>

I think that a verbatim copy of the email seems like something set on
stone, when in fact it is just my opinion and not as well written as
it could have been. I converted it to a set of bullet points so people
can add/remove/edit more freely.

Cheers,

Manuel.

RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

[Grigori Fursin]

Looks good! Thanks!
By the way, I sent it to the HiPEAC mailing lists too ...
Cheers,
Grigori

-----Original Message-----
From: Manuel López-Ibáñez [mailto:lopezibanez@gmail.com] 
Sent: Tuesday, April 27, 2010 6:02 PM
To: Grigori Fursin
Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.rohou@inria.fr; David Edelsohn
Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On 27 April 2010 14:27, Grigori Fursin <gfursin@gmail.com> wrote:
> Hi all,
>
> I created the page on GCC Wiki with this info:
> http://gcc.gnu.org/wiki/GCC_Research
>
> Please, feel free to update or rewrite completely
> (if you feel that something is wrong, etc)...
>

I think that a verbatim copy of the email seems like something set on
stone, when in fact it is just my opinion and not as well written as
it could have been. I converted it to a set of bullet points so people
can add/remove/edit more freely.

Cheers,

Manuel.