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.
