From cTuning.org
(Difference between revisions)
| Line 4: | Line 4: | ||
* ''Grigori Fursin, INRIA'': I would like to discuss further extensions to [[CTools:ICI|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... | * ''Grigori Fursin, INRIA'': I would like to discuss further extensions to [[CTools:ICI|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... | ||
| + | |||
| + | * ''Konrad Trifunovic'': | ||
| + | <pre> | ||
| + | 1. | ||
| + | Are you interested in contributing to the Graphite, and what would | ||
| + | You like to use Graphite for? | ||
| + | |||
| + | 2. We have some limitiations 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? | ||
| + | |||
| + | 3. 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? | ||
| + | |||
| + | 4. 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? | ||
| + | |||
| + | 5. 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... | ||
| + | |||
| + | other ideas: | ||
| + | Coupling Graphite and plugins... | ||
| + | </pre> | ||
Revision as of 11:11, 23 January 2010
Assorted questions for the GROW'10 workshop panel:
- Albert Cohen, INRIA: I'd love to raise the issue about learning curve and development productivity with GCC code base.
- Grigori Fursin, INRIA: 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...
- Konrad Trifunovic:
1. Are you interested in contributing to the Graphite, and what would You like to use Graphite for? 2. We have some limitiations 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? 3. 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? 4. 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? 5. 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... other ideas: Coupling Graphite and plugins...