similar to: [LLVMdev] LLVM Loop Vectorizer (Nadav Rotem)

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Hal Finkel > Sent: Monday, October 08, 2012 1:35 AM > > I'd like to add that, mostly through Tobi's efforts, we were able to have isl (the > integer set library) on which Polly depends relicensed such that it is now > distributed under the MIT

It would be great to get "accurate" dependence analysis from polyhedral framework. Anyone working on making polly into analysis+Transforms framework? -Prashantha -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sahasrabuddhe, Sameer Sent: Monday, October 08, 2012 9:03 AM To: Hal Finkel; Javed Absar Cc: llvmdev at

Javed, I'd like to add that, mostly through Tobi's efforts, we were able to have isl (the integer set library) on which Polly depends relicensed such that it is now distributed under the MIT license, and thus Polly should be eligible for inclusion as some of LLVM's core analysis and transformation passes. -Hal ----- Original Message ----- > From: "Javed Absar"

On 10/08/2012 06:58 AM, Rao, Prashantha wrote: > It would be great to get "accurate" dependence analysis from polyhedral framework. Anyone working on making polly into analysis+Transforms framework? Polly is already divided into analysis and transformation passes. However, the interface is currently specific to the needs of polyhedral optimizers. If there is interest to use e.g.

Hi Javed, Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They started with a single-block loops, and later they added

On 10/08/2012 06:02 AM, Nadav Rotem wrote: > Hi Javed, > > Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They

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

Hi Tobi,  I have some concerns about adding Polly into LLVM proper. I think that it's great that Polly is a part of the LLVM umbrella of projects, like Clang and LLDB. However, I am not convinced that Polly belongs in the LLVM compiler library. LLVM is a major dependency for so many external projects. Rust, Swift, GPU drivers by different vendors, and JIT compilers all rely on LLVM. Projects

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

Hi, Nadav, Chris, et al., If you've not already seen it, we had a long discussion about incorporating Polly into LLVM on llvm-dev, http://lists.llvm.org/pipermail/llvm-dev/2017-September/117063.html (with a continuation in October: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118125.html) with a lot of detailed information. I think it is important, first, that we agree on the goals

On Oct 7, 2012, at 11:53 PM, Tobias Grosser <tobias at grosser.es> wrote: > As the design of the vectorizer is a very hot topic, I was wondering if there will be a BoF session on the LLVM conference? Nadav, you have not proposed one by accident? I proposed a BoF, and (if accepted) we can start discussing the design of the llvm loop vectorizer and the infrastructure that we need for

On Mon, Jun 21, 2010 at 1:12 AM, Javed Absar <javed.absar at gmail.com> wrote: > 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

Dear LLVM community, hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. With the latest LLVM release out of the way and a longer development phase starting, we would like to restart the process of including Polly and isl into core LLVM to bring changes in early on before the next LLVM release. Short summary: * Today Polly is already part of each LLVM release (and

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also

Hi, We are starting to work on an LLVM loop vectorizer. There's number of different projects that already vectorize LLVM IR. For example Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, AnySL, just to name a few. I think that it would be great if we could collaborate on the areas that are shared between the different projects. I think that refactoring LLVM in away that

Hi Hal, Tobias, Michael, and others, I'd like to add my view (and a proposal) to this discussion and I apologize directly for doing this so late*. I also want to apologize because this email is long, contains various technical details and also argumentations that might need more justification. However, I am happy to provide further information (and/or examples) to explain my views if

Thanks Tobias, I am really looking forward to trying out the true integrated Polly and I hope to provide good positive feedback. Since I am maintaining an "out of tree" target, I generally update on each release - I call it the Big Bang update because of the difficulties this presents. At the moment our target is based on the v5.0.0 sources, and I hope to update to the v6.0.0 sources

Thanks Reid/Jonathon for your replies. Reid, An important case against module level flags is that it wont allow changing or resetting section names e.g. int a; #pragma clang section bss = "xyz" int b; In case above, users would like to see only 'b' placed in 'xyz' and not 'a' as well. Link pointed to by Jonathon seems to require same behavior.

I think we should try to abstract the costs of instructions of various targets instead of trying to replicate them exactly. The coarser the costing infrastructure the more robust will be the vectorization pass. Also this eliminates/reduces the need of updating the costing infrastructure as and when new h/w reduces the cost(s) of existing instructions. - Dibyendu -----Original Message----- From:

Hi, Johannes, Thanks for writing this. I certainly think you have the right idea in terms of the desired end state and modular design. On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > Hi Hal, Tobias, Michael, and others, > > I'd like to add my view (and a proposal) to this discussion and I > apologize directly for doing this so late*. I also want to apologize > because this