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 <gfur...@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.
