similar to: [LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)

Hi, On 08/10/2012 11:06 PM, Hal Finkel wrote: > I'd like to see support in clang/LLVM for multi-core parallelism, > especially support for OpenMP. I think that the best way to do this is > by designing an LLVM-based API (metadata and intrinsics) for > expressing parallelism constructs, and having clang lower OpenMP code > to that API. This will allow maximal preservation

On Mon, 13 Aug 2012 12:38:02 +0300 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi, > > On 08/10/2012 11:06 PM, Hal Finkel wrote: > > I'd like to see support in clang/LLVM for multi-core parallelism, > > especially support for OpenMP. I think that the best way to do > > this is by designing an LLVM-based API (metadata and intrinsics) >

On Tue, 2 Oct 2012 14:28:25 +0000 "Adve, Vikram Sadanand" <vadve at illinois.edu> wrote: > Hal, Andrey, Alexey, > > From the LLVM design viewpoint, there is a fundamental problem with > both Hal's approach and the Intel approach: both are quite > language-specific. OpenMP is a particular parallel language, with > particular constructs (e.g., parallel

I am not an optimizer guy, but, I am just thinking, if we can solve the problems that we are discussing in this mail chain, by introducing a middle-end in between front-end and LLVM. We may need to introduce GGC GIMPLE kind of IR (or any new suitable IR) in the middle-end so that front-end can produce this new IR, middle-end can consume it, and do all the parallelization and subsequent

Hal, Andrey, Alexey, >From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific. OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics. LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it. I've

> (d) Add a small number of LLVM intrinsics for region or loop annotations, > represent the directive/clause names using metadata and the remaining > information using arguments. > > Here we're proposing (d), I think this would serve the goal of communicating source-level directives and annotations down to LLVM passes and back-ends, while deferring inlining and

On Tue, 14 Aug 2012 10:22:35 +0300 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 08/13/2012 10:54 PM, Hal Finkel wrote: > > I had thought about uses for shared-memory OpenCL implementations, > > but I don't know enough about the use cases to make a specific > > proposal. Is your metadata documented anywhere? > > It is now a quick "brute

Dear all, This RFC proposes three new LLVM IR instructions to express high-level parallel constructs in a simple, low-level fashion. For this first stage we prepared two commits that add the proposed instructions and a pass to lower them to obtain sequential IR. Both patches have be uploaded for review [1, 2]. The latter patch is very simple and the former consists of almost only mechanical

Mehdi, thanks for good questions. >>>>>Something isn’t clear to me about how do you preserve the validity of the region annotations since regular passes don’t know about the attached semantic? There are some small changes we have to make in some optimizations to make sure the optimizations does not validation attached annotation semantics. 1) provide hand-shaking / query utils for

Hi, Sorry for the hiatus, busy time at my university. :) After a false start and some (hopefully cogent) thought, I am now of the opinion that it will be better to have llvm natively support a somewhat different notion of parallel computation and have the frontend lower OpenMP directives (and possibly other such things) into the same. In short, I propose a intrinsic based approach which hinges

On 08/13/2012 10:54 PM, Hal Finkel wrote: > I had thought about uses for shared-memory OpenCL implementations, but > I don't know enough about the use cases to make a specific proposal. Is > your metadata documented anywhere? It is now a quick "brute force hack", that's why I got interested in your proposal. We just wanted to communicate the OpenCL work item information

> On Mar 8, 2017, at 10:55 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Mar 8, 2017, at 5:36 AM, Johannes Doerfert <doerfert at cs.uni-saarland.de> wrote: >> >> <mehdi.amini at apple.com>, >> Bcc: >> Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- IR extension >> Reply-To: >>

A quick update, we have been looking through all LLVM passes to identify the impact of "IR-region annotation", and interaction issues with the rest of LoopOpt and scalarOpt, e.g. interaction with vectorization when you have schedule(simd:guided: 64). What are the common properties for optimizer to know on IR-region annotations. We have our implementation working from O0, O1, O2 to O3.

Hi, Le 02/10/2012 19:29, Hal Finkel a écrit : > On Mon, 01 Oct 2012 22:56:50 -0700 > Chris Lattner <clattner at apple.com> wrote: >> On Oct 1, 2012, at 10:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On Mon, 01 Oct 2012 21:26:54 -0700 >>> Chris Lattner <clattner at apple.com> wrote: >>>> On Oct 1, 2012, at 6:16 PM, greened at

<mehdi.amini at apple.com>, Bcc: Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- IR extension Reply-To: In-Reply-To: <20170224221713.GA931 at arch-linux-jd.home> Ping. PS. Are there actually people interested in this? We will continue working anyway but it might not make sense to put it on reviews and announce it on the ML if nobody cares. On 02/24,

On Mon, 01 Oct 2012 22:56:50 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Oct 1, 2012, at 10:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Mon, 01 Oct 2012 21:26:54 -0700 > > Chris Lattner <clattner at apple.com> wrote: > > > >> > >> On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > >>

+1, tokens are the current True Way to create single-entry multi-exit regions. Your example for an annotated loop would look like: %region = call token @llvm.openmp.regionstart(metadata ...) ; whatever parameters you need here loop call void @llvm.openmp.regionend(token %region) If you use tokens, I would recommend proposal (c), where you introduce new intrinsics for every new kind of region,

On 03/08/2017 12:44 PM, Johannes Doerfert wrote: > I don't know who pointed it out first but Mehdi made me aware of it at > CGO. I try to explain it shortly. > > Given the following situation (in pseudo code): > > alloc A[100]; > parallel_for(i = 0; i < 100; i++) > A[i] = f(i); > > acc = 1; > for(i = 0; i < 100; i++) > acc = acc *

Hi Johannes, > I am especially curious where you get your data from. Tapir [0] (and to > some degree PIR [1]) have shown that, counterintuitively, only a few changes > to LLVM passes are needed. Tapir was recently used in an MIT class with a > lot of students and it seemed to work well with only minimal changes > to analysis and especially transformation passes. TAPIR is an

The IR-region annotation we proposed is as below, there is no @llvm.parallel.for.iterator()..... There is no change to loop CFG. alloc A[100]; %t = call token @llvm.region.entry()["parallel.for"()] for(i = 0; i < 100; i++) { a[i] = f(i); } @llvm.region.exit(%t)() ["end.parallel.for"()] Xinmin -----Original Message----- From: Johannes Doerfert