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

["Manuel López-Ibáñez" <lopezibanez@gmail.com>]

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.