This is the mail archive of the
mailing list for the GCC project.
Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 11 Apr 2010 15:54:12 +0300
- Subject: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
We would like to share notes from the lively panel discussion at
GROW'10 (GCC Research Opportunities Workshop) that took place at the
end of January in Pisa, Italy (alongside the HiPEAC conference).
The main topic of the discussion was:
How to make GCC more attractive to researchers,
and how GCC can benefit from researchers?
Here is the list of major points and wishes raised by participants:
* Need to encourage cleanup/infrastructure work on GCC and provide
stable/flexible/extensible APIs (the question is how to encourage such
* Encourage people to work on infrastructure and full implementation
that actually works: Lobby for high quality conferences to reserve a quota
of the accepted papers to papers that focus on *implementation* work (and
start with HiPEAC!)
* Follow up to the above: Encourage research that actually works:
Lobby for conferences to favor research work that is tested on a realistic
environment (e.g. pass all of SPECcpu...), and that is reproducible.
Then GCC and the community could immediately benefit from the results and
not wait for many years before someone decides to reproduce/redo research
ideas in GCC.
* Get statistics on percentage of papers/projects that use compilers other
than GCC, and ask them why... (By the way, why was OpenCL implemented only
on LLVM and not on 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).
* 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.
* Need a simple pass manager that can list all available passes
and allow any scheduling (providing dependency information).
* Make more visible/accessible guides for building/extending GCC.
* Better advertize Google Summer of Code, and provide more mentoring.
* Send feedback on which plugin events are desired to add to next releases
* 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...?
We've collected these and other comments/suggestions before/at/after the
workshop, on the GROW'10 wiki page:
We hope these notes would help improve GCC and its appeal/usability for
researches (or at least raise more discussion!)
Grigori Fursin and Dorit Nuzman