search for: ergawi

Hello, Below is a proposal for a GSoC project that I would like to work on this year. Your input and feedback is much appreciated. Background: ========= My name is Kareem Ergawy and I currently work as part of the PIR project. PIR is an extension of the IR to support fork-join parallelism that is currently under review [1, 2, 3, 4]. Goals: ===== As a GSoC project, here I propose an

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.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,

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.

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

".... the problem Mehdi pointed out regarding the missed initializations of array elements, did you comment on that one yet?" What is the initializations of array elements question? I don't remember this question. Please refresh my memory. Thanks. I thought Mehdi's question is more about what are attributes needed for these IR-annotation for other LLVM pass to understand and

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 *

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

I assume the referring case is something like below, right? #pragma omp parallel num_threads(n) { #pragma omp critical { x = x + 1; } } If that is the case, the programmer is already writing the code that is not "serial equivalent". Our representation for parallelizer is %t = @llvm.region.entry()["omp.parallel"(),

> On Mar 8, 2017, at 11:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 03/08/2017 01:24 PM, Tian, Xinmin wrote: >> I assume the referring case is something like below, right? >> >> #pragma omp parallel num_threads(n) >> { >> #pragma omp critical >> { >> x = x + 1; >> } >> }