This is the mail archive of the mailing list for the GCC project.

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

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

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!!!

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

> * 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".



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