similar to: [LLVMdev] "Graphite" for llvm [building infrastructure]

Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] "Graphite" for llvm [building infrastructure]"

2010 Jan 06
1
[LLVMdev] "Graphite" for llvm [building infrastructure]
On 01/05/10 14:45, ether wrote: > hi Tobi, > > i just added the Poly > library(http://wiki.llvm.org/Polyhedral_optimization_framework) to llvm > build system, which only contain a toy pass "Poly". > i think we could add the polyhedral optimization stuff in to this library. > > it was test under cmake+visual studio 2009, and i also add the library > build rule
2010 Mar 25
1
[LLVMdev] [Summer of Code ideas] The polyhedral optimization framework for LLVM
Hi all, I would like to participate in Google's Summer of Code this year, for LLVM(Polly), The polyhedral optimization framework ( http://wiki.llvm.org/Polyhedral_optimization_framework ) which i am already working on with Tobias. Polly is a polyhedral optimization framework for llvm, which similar to Graphite for gcc (http://gcc.gnu.org/wiki/Graphite). The main work flow of Polly is:
2009 Dec 26
3
[LLVMdev] "Graphite" for llvm
Hi ether, On 12/26/09 13:06, ether zhhb wrote: > hi, > > dose anyone going/planning to add something like > Graphite(http://gcc.gnu.org/wiki/Graphite) in gcc to llvm(or that > should be implement at the level of clang?)? I already looked into implementing something like Graphite for LLVM. However just recently, so I have not released any code yet. As soon as some code is
2009 Dec 29
3
[LLVMdev] "Graphite" for llvm
On 12/27/09 10:18, ether wrote: > hi Tobi , > > that sounds greate :D > > On 2009-12-27 5:43, Tobias Grosser wrote: >> I already looked into implementing something like Graphite for LLVM. >> However just recently, so I have not released any code yet. As soon as >> some code is available I will post patches. > whats its status? do you need any help? Very
2010 May 08
0
[LLVMdev] Auto-Vectorization in LLVM
On 05/06/10 10:40, Renato Golin wrote: > On 6 May 2010 05:34, Chris Lattner<clattner at apple.com> wrote: >> On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: >>> I would also like to know if there is any progress/future plans to >>> include this >>> in the main trunk? >> >> Unfortunately, nothing came of this project AFAIK, maybe Devang
2010 Jun 21
0
[LLVMdev] Speculative Loop Parallelization on LLVM IR
Hi Tobias: Thanks for replying . So if I understand correctly, in LLVM currently, the Polyhedral model is being built ( LLVM IR -------> Poly Model ----------> LLVM IR ). This is for compile-time optimizations of loop-nests [e.g. loop-transformations to expose parallelism or improve locality etc]. Yes, thats great for optimizing loop-nests. As an additional, since the real value of LLVM
2011 Jan 08
0
[LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly
On 01/06/2011 10:59 AM, Renato Golin wrote: > On 6 January 2011 15:16, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >>> The main idea is, we separate the transform passes and codegen passes >>> for auto-parallelization and vectorization (Graphite[2] for gcc seems >>> to taking similar approach for auto-vectorization). > > I agree with Ether. >
2009 Dec 27
0
[LLVMdev] "Graphite" for llvm
hi Tobi , that sounds greate :D On 2009-12-27 5:43, Tobias Grosser wrote: > I already looked into implementing something like Graphite for LLVM. > However just recently, so I have not released any code yet. As soon as > some code is available I will post patches. whats its status? do you need any help? > A general plan to implement polyhedral transformations in LLVM: > > 1.
2011 Jan 06
0
[LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly
On 01/06/2011 03:38 AM, ether zhhb wrote: > Hi, > > I just have a detail look at the code of Polly[1], it seems that Polly > start to support some basic auto-parallelization stuffs. This is true. However still work in progress. I hope we can soon show some interesting results. > I have some idea to improve the current auto-vectorization > and parallelization approach in
2011 Jan 06
2
[LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly
On 6 January 2011 15:16, Tobias Grosser <grosser at fim.uni-passau.de> wrote: >> The main idea is, we separate the transform passes and codegen passes >> for auto-parallelization and vectorization (Graphite[2] for gcc seems >> to taking similar approach for auto-vectorization). I agree with Ether. A two-stage vectorization would allow you to use the simple loop-unroller
2010 Mar 04
0
[LLVMdev] region pass - new pass for llvm
How is the patch compressed? I don't know how to open the file with .7z suffix. Evan On Feb 27, 2010, at 10:12 PM, ether zhhb wrote: > hi all, > > The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the
2010 Jun 18
4
[LLVMdev] Speculative Loop Parallelization on LLVM IR
Hi Javed, On 06/18/10 14:07, Javed Absar wrote: > Hi: > I worked on loop-optimizations techniques previously using ORC. > Currently i see lots of research on speculative parallelization of > loops ... specially because multicores [for embedded systems] is > becoming popular. In other words, because you have > multiple cores, you can start some loops [Fast-Track] as if there is
2010 Feb 28
2
[LLVMdev] region pass - new pass for llvm
hi all, The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the nature loop. The original purpose to add such a pass to llvm system is to allow us find out the static control part (SCoP) for the polyhedral
2010 Mar 08
1
[LLVMdev] region pass - new pass for llvm
On 03/08/2010 12:36 PM, Renato Golin wrote: > Hi Tobias, > > >> What do you mean with a closed CFG? > > Closed region, one entry/one exit. > > >>> Still, non-affine loops can be converted to affine loops in many ways >> How would you do this? As we use the scalar evolution analysis to analyze >> the loops, we do not depend on any syntactic form.
2010 Oct 05
0
[LLVMdev] Multithreaded code generation
On 10/05/2010 09:42 AM, hamed hamzehi wrote: > Hi > yes, I'm asking for any advice, I want to implement multithreaded code > generator in LLVM. > tnx Hi, this generally depends which kind of code you want to multithread, because generally this is a difficult problem. However, if you limit yourself for the moment to loops that fit into the polyhedral model, you can take
2010 Oct 05
2
[LLVMdev] Multithreaded code generation
Hi, In fact I have some theory on instruction level parallelism( i have a partitioning algorithm), then first of all, i want to generate a multithreaded code from LLVM IR (in assembly level) with a given partitioning. My problem is how can i use a thread library(like Pthread) or OS system calls in LLVM IR to create and manage threads? --- On Tue, 10/5/10, Tobias Grosser <grosser at
2009 Dec 28
2
[LLVMdev] "Graphite" for llvm
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
2010 Mar 04
3
[LLVMdev] region pass - new pass for llvm
That looks like something from 7-zip (http://www.7-zip.org/). Ether, can you re-send either as a plain-text attachment, or if you need to use an archive, .zip or .tar.gz so it's a bit more standard for those of us not working on a Windows platform? Thanks! -Jim On Mar 4, 2010, at 11:15 AM, Evan Cheng wrote: > How is the patch compressed? I don't know how to open the file with .7z
2010 May 06
1
[LLVMdev] Auto-Vectorization in LLVM
On 6 May 2010 05:34, Chris Lattner <clattner at apple.com> wrote: > On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: >> I would also like to know if there is any progress/future plans to >> include this >> in the main trunk? > > Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. I looked for it and couldn't find any, too. I found
2009 Dec 29
0
[LLVMdev] "Graphite" for llvm
Tobias Grosser wrote: > The way to go is the scoplib format (propably extended by quantified > variables). This format could be extracted from graphite easily and > could also be created in LLVM. > What we need to get back into LLVM is only the new optimized schedule > described e.g. as cloog like scattering functions. These can be parsed > easily. The real code generation