similar to: Round tables

In the 2018 LLVM DevMtg [1], I presented some shortcomings of how LLVM optimizes loops. In summary, the biggest issues are (a) the complexity of writing a new loop optimization pass (including needing to deal with a variety of low-level issues, a significant amount of required boilerplate, the difficulty of analysis preservation, etc.), (b) independent optimization heuristics and a fixed pass

Thanks Chris for CCing us. I remember Michael's presentation and suggestion to consider Roslyn's design and experience. I'll be glad to discuss further in April. Michael, we can also talk later this week if you'd like. I'll send you a separate email. Loop transformations in MLIR take many different paths. Polyhedral affine-to-affine, generative/lowering in linalg, and also

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Chris Lattner < clattner at nondot.org>: > The central idea is to use a modifiable loop tree -- similar to > LoopInfo -- as the primary representation. LLVM-IR is converted to a > loop tree, then optimized and finally LLVM-IR is generated again for > subtrees that are considered profitable. This is not a new concept, it > has already

Am Fr., 7. Feb. 2020 um 17:03 Uhr schrieb Chris Lattner <clattner at nondot.org >: > > The discussion here is valuable for me, helping me to make my > > presentation about it at EuroLLVM as relevant as possible. My current > > idea is to take a complex loop nest, and compare optimizing it using > > red/green DAGs and traditional pass-based optimizers. > > Cool.

On Fri, Oct 13, 2017 at 5:13 PM, Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 2017-10-14 1:29 GMT+02:00 Saito, Hideki via llvm-dev < > llvm-dev at lists.llvm.org>: > > I'm also sorry that I'm not commenting on the main part of your RFC in > this reply. I just want to focus on > > one thing here. > > > >

Status Update on VPlan ---- where we are currently, and what's ahead of us ==========================================================   Goal: ----- Extending Loop Vectorizer (LV) such that it can handle outer loops, via uplifting its infrastructure with VPlan. The goal of this status update is to summarize the progress and the future steps needed.   Background: ----------- This is related to

Am Fr., 10. Jan. 2020 um 16:10 Uhr schrieb Renato Golin <rengolin at gmail.com>: > On Fri, 3 Jan 2020 at 11:27, Michael Kruse via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 1. Candidate selection through cost function > > -------------------------------------------- > > Instead of needing to know which transformation is profitable before > >

Am Mi., 15. Jan. 2020 um 20:27 Uhr schrieb Chris Lattner < clattner at nondot.org>: > One you achieve consensus on data structure, there is the question of what >> IR to use within it. I would recommend starting with some combination of >> “existing LLVM IR operations + high level control flow representation”, >> e.g. parallel and affine loops. The key here is that

Hey folks, Do we have proposals for an HPC focused BoF at EuroLLVM? I'd like to discuss the current efforts around integrating Polly, parallel IR efforts and vectoriser support in VPlan (like outer loop), as well as coordination on the next steps around Flang. -- cheers, --renato

Michael, [Sorry that I don't have you in To:. I don't have your addr that I can use since I'm replying through digest.] I'm also sorry that I'm not commenting on the main part of your RFC in this reply. I just want to focus on one thing here. Proposed Loop Optimization Framework ------------------------------------

Hi all, At the Barcelona Supercomputing Center, we have been working on an end-to-end vectorizer using scalable vectors for RISC-V Vector extension in context of the EPI Project <https://www.european-processor-initiative.eu/accelerator/>. We earlier shared a demo of our prototype implementation  (https://repo.hca.bsc.es/epic/z/9eYRIF, see below) with the folks involved with LLVM

Hi all, The TensorFlow team at Google has been leading the charge to build a new set of compiler infrastructure, known as the MLIR project <https://github.com/tensorflow/mlir>. The initial focus has been on machine learning infrastructure, high performance accelerators, heterogeneous compute, and HPC-style computations. That said, the implementation and design of this infrastructure is

On 03/20/2018 05:05 AM, Michael Kruse wrote: > There's none yet according to http://llvm.org/devmtg/2018-04/#talks > > Unfortunately, I won't be present, but IMHO it would be nice to have one. I agree. This seems like a good idea.  -Hal > > Michael > > > > 2018-03-20 7:50 GMT+01:00 Renato Golin <renato.golin at linaro.org>: >> Hey folks, >>

On 31 July 2018 at 21:10, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi David, >> >> Let me put the last two comments up: >> >>> > But we're trying to represent slightly different techniques >>> > (predication, vscale change) which need

Am Mo., 27. Jan. 2020 um 22:06 Uhr schrieb Uday Kumar Reddy Bondhugula < uday at polymagelabs.com>: > Hi Michael, > > Although the approach to use a higher order in-memory abstraction like the > loop tree will make it easier than what you have today, if you used MLIR > for this representation, you already get a round trippable textual format > that is *very close* to your

Am Mi., 5. Feb. 2020 um 18:13 Uhr schrieb Chris Lattner <clattner at nondot.org>: > If I understand your claims, you are claiming both that red/green trees are essential for a loop optimizer, and that this essential nature “justifies” the cost of reinventing an entire compiler infrastructure is lower than the benefit of using (e.g.) MLIR to do this. I haven’t seen evidence of either

Hi, A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please? I'm at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools ::

Hi, I am extending LLVM for HPC applications. As one of them, I am trying to make MachinePipeliner available on AArch64 + Scalable Vector Extension environment. MachinePipeliner is currently used only by Hexagon CPU. Since it is a very portable implementation, I think that it will actually work just by adding a little code for many CPUs(See Code [2]). The current MachinePipeliner is written on

** *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

There's none yet according to http://llvm.org/devmtg/2018-04/#talks Unfortunately, I won't be present, but IMHO it would be nice to have one. Michael 2018-03-20 7:50 GMT+01:00 Renato Golin <renato.golin at linaro.org>: > Hey folks, > > Do we have proposals for an HPC focused BoF at EuroLLVM? > > I'd like to discuss the current efforts around integrating Polly,