ether wrote:>> The polyhedral loop description is simple and not compiler depended. >> Therefore external tools like LooPo (automatic parallelization), Pluto >> (optimization in general) > i had contacted the author a week ago, and if we use it, we need a IR > generator in llvm side to extract SCoP, and the corresponding parser in > Pluto side that read, then a backend for cloog and the corresponding in > parser llvm that read those stuff back to llvm. :) >> or even Graphite > hows the statue of PCP? could us just use the PCP language with annotation?Hi all, PCP is only partially implemented: conversion out of PCP to Graphite is not implemented, but the existing code would definitely help anybody working in interfacing other tools with PCP. The main people to contact are "Sjodin, Jan" <Jan.Sjodin at amd.com> Sebastian Pop <sebpop at gmail.com> Work on PCP has stalled because Jan has left for another group. In the hort term, Tobias is right that the best way to interface tools is to use the scoplib format and library from Louis-Noel Pouchet (PoCC). In any case, work on either PCP or scoplib will be beneficial. The community of polyhedral compilation experts is small, and its openly available output is already diminished by two proprietary development projects at IBM and Reservoir Labs. I strongly wish that any effort within LLVM will be wise enough to join forces with Graphite :-) Albert
On Mon, Dec 28, 2009 at 05:05, Albert Cohen <Albert.Cohen at inria.fr> wrote:> PCP is only partially implemented: conversion out of PCP to Graphite is not > implemented,Actually Gimple to PCP to Graphite is implemented in some extent, but there still are plenty of bugs and we should work on the out of Graphite to PCP to Gimple/LLVM if we want to get rid of all these bugs. Also the patches for these are not yet in the Graphite branch, just in local trees for now.> but the existing code would definitely help anybody working in > interfacing other tools with PCP. The main people to contact are > "Sjodin, Jan" <Jan.Sjodin at amd.com> > Sebastian Pop <sebpop at gmail.com> > > Work on PCP has stalled because Jan has left for another group. >Jan, what's the plan to integrate PCP in GCC and/or LLVM?> In the hort term, Tobias is right that the best way to interface tools is to > use the scoplib format and library from Louis-Noel Pouchet (PoCC). > > In any case, work on either PCP or scoplib will be beneficial. The community > of polyhedral compilation experts is small, and its openly available output > is already diminished by two proprietary development projects at IBM and > Reservoir Labs. I strongly wish that any effort within LLVM will be wise > enough to join forces with Graphite :-) > > Albert >
> Jan, what's the plan to integrate PCP in GCC and/or LLVM?Currently thre is no concrete plan, or at least nothing immediate. I believe a modular approach to loop transformations is desirable. The main purpose of PCP is to get a common interface between a lower level IR like SSA and higher level optimizations done on structured code, but one could also directly translate from a front-end to PCP. On the analysis/transformation side there could be several implementations, including the polyhedral model. What needs to be done is to clearly specify how different information should be encoded. Debug info, costs for heuristics etc. The second benefit of having PCP is to be able to read and write code fragments to a file. LLVM has some of these features already, but SSA is not the right level. Implementing views on top of SSA might be possible, using program structure trees and a lot of bookkeeping, but that will also reduce the modularity code. Front End <- -> Polyhedral Model \ / ==> PCP <= / ^ \ SSA <- | -> Classical Loop transforms | v Text I believe it would not be too much work to LLVM-ify the current implementation of PCP since it is all written in C++. Most of the work would be to translate implementations of PCP data ADTs to use the LLVM ones. There are however a few areas that need to be addressed: 1. Memory management. 2. Error handling.3. Improved type system, since we need to be able to reason better about induction variables and size of data. Alignment may come in here as well. 4. Different properties must be encoded and some should perhaps put into the PCP language itself e.g. reduction operations. I can look into how the current code can be released, or contributed in order for other people to work on it. - Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091228/1129c8e0/attachment.html>