Following up discussion after GROW'10 workshop panel on "GCC as a research compiler":
After GCC 4.5 has been released, there have been new discussions about how to use GCC as a research compiler. There are still some drawbacks such as lack of stable API, lack of full modularity, old and messy code base but slowly and gradually GCC is improving. And of course, there are many obvious benefits such as mature front-ends for C,C++ and Fortran, availability of many aggressive transformations, many supported architectures, are maybe more importantly that this open-source compiler is used in so many projects, that researchers can have an immediate impact on the community if they implement their successful ideas in GCC.
However, it is not always easy to work with GCC community since many GCC developers are focusing on some specific projects and may not have enough time to implement some fancy new features or clean/modularize code for not very clear purposes and far future. After GROW 2010 workshop, we decided to ask GCC developers to give some suggestions to the researchers (who may want to use GCC for their research)about how to cooperate with the GCC community.
Here are a few links to those discussions at GCC mailing list:
Another interesting discussion started in April, 2010 was about "Why not contribute? (to GCC)" and had more than 100 responses:
Some informal suggestions on the interaction with the GCC community
- 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.
- 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 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.
You patch may not receive much feedback. There are many reason why reviewers may overlook your patch: lack of time, mistake deleting, not clear who should review it, patch is too complex, not the appropriate development stage. Even patches from experience developers require several pings. "Pinging" a patch after two or more weeks without an answer is common practice. More examples of pinging.
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.
You only need to convince the decision-makers. Almost the only feed-back that matters is the one given by the decision-makers. In the case of a patch, the maintainers of the area touched by the patch (see MAINTAINERS file). If those people are in favour, it doesn't matter who is against it. Of course, it many people are against it, then the decision-makers may change their mind It also works the other way around, so pleasing people may help to change the opinion of the decision-makers. But your goal is to get the approval of the people with the power to approve.
- An example of how *not* to get things done is the "maybe we" attitude. It is likely to get no feedback, negative feedback, or positive feedback that sounds a bit negative (like "be my guest"):
- 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:
- Send a new email with a descriptive subject "A new gcc mailing list for experimenting with gcc"
- 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
- 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. (See point above)
Various on-going projects that may be of interest to the researchers who use GCC or plan to use it in the future:
cTuning Wiki mirror:
GCC has a mechanism for "external" plugins (since gcc 4.5) and some hooks calling plugin code from inside GCC. Researchers could experiment new ideas by developing (GPLv3 licensed) plugins. The MELT plugin (or branch) could also interest researchers, since it provides them with a powerful lispy language (with pattern matching) to easily code GCC extensions in.
The most important work is still to understand GCC internals. This is a prerequisite for any work on GCC (with or without plugins or MELT).