Dissemination:Workshops:GROW10:Panel Questions

Revision as of 15:32, 29 March 2010 by Gfursin (Talk | contribs)

Assorted questions for the GROW'10 workshop panel:

Before GROW'10 panel:

Albert Cohen: I'd love to raise the issue about learning curve and development productivity with GCC code base.

Grigori Fursin: I would like to discuss further extensions to ICI and MILEPOST GCC needed to provide compiler/architecture/language independent API for program analysis and optimization (unified data exchange format?) that may be needed for our further research on fine-grain iterative compilation, reactive iterative compilation, collective optimization and split-compilation...

- Are you interested in contributing to the Graphite, and what would You like to use Graphite for?

- We have some limitations due to the nature of the polyhedral model (static analysis). We are interested in extending static approach to more dynamic approaches. Anyone interested in this topic?

- We are interested in a ways of representing the concurrency in the GIMPLE. What we would like to achieve is the following: the original source code is extended with pragmas (probably the OpenMP or similar) which give hints to the compiler as to which loops or regions of code are parallel etc. Graphite could find this information helpful, so that it can extend the scope of analysis. This wokr concerns not only Graphite but whole GCC. Already a paper on this?

- Anyone working on automatic parallelization: if you are working on the parallelization methods based on polyhedral model (scheduling based) and you are using one of the source-to-source tools (PLUTO, PoCC, LooPo) why do not give Graphite a try?

- Anyone working on polyhedral model for different purposes (for example static analysis, automatic verification) is welcome to have a look at Graphite. We use PPL (Parma Polyhedra Library), originally made by the verification people in mind...

Notes from the GROW'10 Panel: (recorded and updated by Dorit Nuzman and Grigori Fursin)

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 infrastructure work?)

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).

Send feedback on which plugin events are desired to add to next releases of GCC.

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...?