similar to: [LLVMdev] [RFC] Progress towards OpenMP support

Hi all, I made some progress on implementing Hal's proposal [1] for implementing OpenMP support in LLVM. The patch I've attached just barely compiles, but I'd like to get some input on the design early on to prevent trouble later. I'd especially like some input on the following points: * Metadata is never mutated or dropped I think it is better to have an analysis pass that

On Tue, 11 Sep 2012 01:21:59 +0530 Sanjoy Das <sanjoy at playingwithpointers.com> wrote: Sanjoy, Thanks for working on this! Comments below... > Hi all, > > I made some progress on implementing Hal's proposal [1] for > implementing OpenMP support in LLVM. The patch I've attached just > barely compiles, but I'd like to get some input on the design early on >

Hi Hal, > My rationale for proposing the self-consistent metadata solution was > that it seemed to be the safest option. If we simply insist that all > relevant passes use the ParallizationMetadata pass, without any > verification, then we could end up with parallelization-unaware passes > silently miscompiling code when parallelization is enabled. Do you have > a way of

On Thu, 13 Sep 2012 09:01:18 +0530 Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Hal, > > > My rationale for proposing the self-consistent metadata solution was > > that it seemed to be the safest option. If we simply insist that all > > relevant passes use the ParallizationMetadata pass, without any > > verification, then we could end up with

Hi Hal, > An alternative approach, which you seem to be proposing, is that the > parallelization reads the metadata up front (and then drops it all). If > a pass does not preserve that analysis, then it will be invalidated, and > the parallelization will be lost. This, indeed, might be a better > approach, but would at least require touching a lot more code (if > nothing else,

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

Hal Finkel <hfinkel at anl.gov> writes: Hi Hal, > As you may know, this is the third such proposal over the past two > months, one by me > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html) This link seems to be broken. I missed your earlier proposal and would like to read it. As with this proposal, I fear any direct parallelization support in LLVM is going to

How are you representing things like various scheduling mechanisms without metadata - extra parameters to intrinsics ? - dibyendu ----- Original Message ----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Wednesday, September 26, 2012 08:36 AM To: Hal Finkel <hfinkel at anl.gov> Cc: llvmdev at cs.uiuc.edu <llvmdev at cs.uiuc.edu>; cfe-dev at cs.uiuc.edu <cfe-dev

Sanjoy Das <sanjoy at playingwithpointers.com> writes: > In short, I propose a intrinsic based approach which hinges on the > concept of a "parallel map". The immediate effect of using intrinsics > is that we no longer have to worry about missing metadata. Moreover, > we are still free to lower the intrinsics in a variety of ways -- > including vectorizing them or

Hal, Thank you for the reply! > As you may know, this is the third such proposal over the past two > months, one by me > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html) > and the other, based somewhat on mine, by Sanjoy > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) Yes, I was aware of your proposal. I hesitated to make any comments

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

On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > Sanjoy Das <sanjoy at playingwithpointers.com> writes: > >> In short, I propose a intrinsic based approach which hinges on the >> concept of a "parallel map". The immediate effect of using intrinsics >> is that we no longer have to worry about missing metadata. Moreover, >> we are still

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: > > > Sanjoy Das <sanjoy at playingwithpointers.com> writes: > > > >> In short, I propose a intrinsic based approach which hinges on the > >> concept of a "parallel map". The immediate

Andrey, I am very glad to see that you're interested in working on this! I have a few comments: As you may know, this is the third such proposal over the past two months, one by me (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html) and the other, based somewhat on mine, by Sanjoy (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) In order for your

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

Hi, > constructs (e.g., parallel regions) and semantics. LLVM is a language- > neutral IR and infrastructure and OpenMP-specific concepts should not This is exactly the reason I proposed [1] -- mirroring the openmp directives in LLVM IR doesn't seem very elegant. The parallelization information in the IR should be general and orthogonal. I do realize that boxing the loops into

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: >> >>> Sanjoy Das <sanjoy at playingwithpointers.com> writes: >>> >>>> In short, I propose a

Hi all, I'd like to put in some effort into this too -- perhaps I can write an backend for libgomp while someone else works on a libmpc one. As far as the architecture is concerned, I concur with what has already been discussed: mapping OpenMP constructs to LLVM intrinsics. I think it would make sense to leave out intrinsics for things like "parallel for", "parallel

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