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