Andrey, Are you still working on this? Thanks again, Hal ----- Original Message -----> From: "Hal Finkel" <hfinkel at anl.gov> > To: "Andrey Bokhanko" <andreybokhanko at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, October 10, 2012 12:19:32 AM > Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR > > > > ----- Original Message ----- > > From: "Andrey Bokhanko" <andreybokhanko at gmail.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: llvmdev at cs.uiuc.edu > > Sent: Wednesday, October 3, 2012 3:15:54 AM > > Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR > > > > Hal, > > > > > While I think that it will be relatively easy to have the > > > intrinsics > > > serve as code-motion barriers for other code that might be > > > threads > > > sensitive (like other external function calls), we would need to > > > think > > > through exactly how this would work. The easiest thing would be > > > to > > > make > > > the intrinsics have having unmodeled side effects, although we > > > might > > > want to do something more intelligent. > > > > Yes, that's exactly the idea. > > Right. You should verify that using the 'unmodeled side effects' tag > does not inhibit the optimizations you seek to preserve. If we need > to work out some other less-restrictive semantics, then we should > discuss that. > > > > > > Where do you propose placing the parallel loop intrinsics calls > > > relative to the loop code? > > > > In preloop ("opening" intrinsic) and postloop ("closing" one). > > > > > Will this inhibit restructuring (like loop > > > interchange), fusion, etc. if necessary? > > > > I guess so... Loops usually deal with reading/writing memory, and > > if > > an intrinsic is marked as "modifies everything", this hardly leaves > > any possibility for [at least] the optimizations you mentioned. > > > > But this is different from what I have in mind. Basically, the plan > > is > > to perform analysis and some optimizations before procedurization, > > and > > do the rest (including loop restructuring) after it. This is not > > mentioned in the proposal (we tried to be succint -- only 20 pages > > long! :-)), but explained in detail in [Tian05] (sorry, the link in > > the proposal doesn't lead you directly to pdf file; use this one > > instead: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3763&rep=rep1&type=pdf). > > With regard to what you're proposing, the paper actually leaves a lot > unexplained. The optimizations that it discusses prior to OpenMP > lowering seem to be, "classical peephole optimizations within > basic-blocks", inlining, and "OpenMP construct-aware constant > propagation" (in addition to some aliasing analysis). If this is > what you plan to do in LLVM as well, are you planning on > implementing special-purpose passes for these transformations, or > re-using existing ones? If you're reusing existing ones, which ones? > And how would they need to be modified to become 'OpenMP aware'? > > Can you please comment on the loop-analysis use case that I outline > here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054078.html > Would this kind of simplification fall under the 'constant > propagation' transformation, or will something else be required? > > What might be most useful is if we develop a set of optimization > tests so that we have a set of use cases from which we can base a > design. Do you already have a set of such tests? I'd be happy to > work with you on this. > > Thanks again, > Hal > > > > > Yours, > > Andrey > > > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Hal, Our proposal is effectively got scrapped by the community, so we are not pushing any further on the approach we proposed before. How about meeting at the LLVM conference to discuss this? Yours, Andrey On Mon, Nov 5, 2012 at 11:05 PM, Hal Finkel <hfinkel at anl.gov> wrote:> Andrey, > > Are you still working on this? > > Thanks again, > Hal > > ----- Original Message ----- >> From: "Hal Finkel" <hfinkel at anl.gov> >> To: "Andrey Bokhanko" <andreybokhanko at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, October 10, 2012 12:19:32 AM >> Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR >> >> >> >> ----- Original Message ----- >> > From: "Andrey Bokhanko" <andreybokhanko at gmail.com> >> > To: "Hal Finkel" <hfinkel at anl.gov> >> > Cc: llvmdev at cs.uiuc.edu >> > Sent: Wednesday, October 3, 2012 3:15:54 AM >> > Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR >> > >> > Hal, >> > >> > > While I think that it will be relatively easy to have the >> > > intrinsics >> > > serve as code-motion barriers for other code that might be >> > > threads >> > > sensitive (like other external function calls), we would need to >> > > think >> > > through exactly how this would work. The easiest thing would be >> > > to >> > > make >> > > the intrinsics have having unmodeled side effects, although we >> > > might >> > > want to do something more intelligent. >> > >> > Yes, that's exactly the idea. >> >> Right. You should verify that using the 'unmodeled side effects' tag >> does not inhibit the optimizations you seek to preserve. If we need >> to work out some other less-restrictive semantics, then we should >> discuss that. >> >> > >> > > Where do you propose placing the parallel loop intrinsics calls >> > > relative to the loop code? >> > >> > In preloop ("opening" intrinsic) and postloop ("closing" one). >> > >> > > Will this inhibit restructuring (like loop >> > > interchange), fusion, etc. if necessary? >> > >> > I guess so... Loops usually deal with reading/writing memory, and >> > if >> > an intrinsic is marked as "modifies everything", this hardly leaves >> > any possibility for [at least] the optimizations you mentioned. >> > >> > But this is different from what I have in mind. Basically, the plan >> > is >> > to perform analysis and some optimizations before procedurization, >> > and >> > do the rest (including loop restructuring) after it. This is not >> > mentioned in the proposal (we tried to be succint -- only 20 pages >> > long! :-)), but explained in detail in [Tian05] (sorry, the link in >> > the proposal doesn't lead you directly to pdf file; use this one >> > instead: >> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3763&rep=rep1&type=pdf). >> >> With regard to what you're proposing, the paper actually leaves a lot >> unexplained. The optimizations that it discusses prior to OpenMP >> lowering seem to be, "classical peephole optimizations within >> basic-blocks", inlining, and "OpenMP construct-aware constant >> propagation" (in addition to some aliasing analysis). If this is >> what you plan to do in LLVM as well, are you planning on >> implementing special-purpose passes for these transformations, or >> re-using existing ones? If you're reusing existing ones, which ones? >> And how would they need to be modified to become 'OpenMP aware'? >> >> Can you please comment on the loop-analysis use case that I outline >> here: >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054078.html >> Would this kind of simplification fall under the 'constant >> propagation' transformation, or will something else be required? >> >> What might be most useful is if we develop a set of optimization >> tests so that we have a set of use cases from which we can base a >> design. Do you already have a set of such tests? I'd be happy to >> work with you on this. >> >> Thanks again, >> Hal >> >> > >> > Yours, >> > Andrey >> > >> >> -- >> Hal Finkel >> Postdoctoral Appointee >> Leadership Computing Facility >> Argonne National Laboratory >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory
Andrey, Yes, that would be great. -Hal ----- Original Message -----> From: "Andrey Bokhanko" <andreybokhanko at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, November 7, 2012 7:00:54 AM > Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR > > Hal, > > Our proposal is effectively got scrapped by the community, so we are > not pushing any further on the approach we proposed before. > > How about meeting at the LLVM conference to discuss this? > > Yours, > Andrey > > On Mon, Nov 5, 2012 at 11:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Andrey, > > > > Are you still working on this? > > > > Thanks again, > > Hal > > > > ----- Original Message ----- > >> From: "Hal Finkel" <hfinkel at anl.gov> > >> To: "Andrey Bokhanko" <andreybokhanko at gmail.com> > >> Cc: llvmdev at cs.uiuc.edu > >> Sent: Wednesday, October 10, 2012 12:19:32 AM > >> Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR > >> > >> > >> > >> ----- Original Message ----- > >> > From: "Andrey Bokhanko" <andreybokhanko at gmail.com> > >> > To: "Hal Finkel" <hfinkel at anl.gov> > >> > Cc: llvmdev at cs.uiuc.edu > >> > Sent: Wednesday, October 3, 2012 3:15:54 AM > >> > Subject: Re: [LLVMdev] [RFC] OpenMP Representation in LLVM IR > >> > > >> > Hal, > >> > > >> > > While I think that it will be relatively easy to have the > >> > > intrinsics > >> > > serve as code-motion barriers for other code that might be > >> > > threads > >> > > sensitive (like other external function calls), we would need > >> > > to > >> > > think > >> > > through exactly how this would work. The easiest thing would > >> > > be > >> > > to > >> > > make > >> > > the intrinsics have having unmodeled side effects, although we > >> > > might > >> > > want to do something more intelligent. > >> > > >> > Yes, that's exactly the idea. > >> > >> Right. You should verify that using the 'unmodeled side effects' > >> tag > >> does not inhibit the optimizations you seek to preserve. If we > >> need > >> to work out some other less-restrictive semantics, then we should > >> discuss that. > >> > >> > > >> > > Where do you propose placing the parallel loop intrinsics > >> > > calls > >> > > relative to the loop code? > >> > > >> > In preloop ("opening" intrinsic) and postloop ("closing" one). > >> > > >> > > Will this inhibit restructuring (like loop > >> > > interchange), fusion, etc. if necessary? > >> > > >> > I guess so... Loops usually deal with reading/writing memory, > >> > and > >> > if > >> > an intrinsic is marked as "modifies everything", this hardly > >> > leaves > >> > any possibility for [at least] the optimizations you mentioned. > >> > > >> > But this is different from what I have in mind. Basically, the > >> > plan > >> > is > >> > to perform analysis and some optimizations before > >> > procedurization, > >> > and > >> > do the rest (including loop restructuring) after it. This is not > >> > mentioned in the proposal (we tried to be succint -- only 20 > >> > pages > >> > long! :-)), but explained in detail in [Tian05] (sorry, the link > >> > in > >> > the proposal doesn't lead you directly to pdf file; use this one > >> > instead: > >> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.3763&rep=rep1&type=pdf). > >> > >> With regard to what you're proposing, the paper actually leaves a > >> lot > >> unexplained. The optimizations that it discusses prior to OpenMP > >> lowering seem to be, "classical peephole optimizations within > >> basic-blocks", inlining, and "OpenMP construct-aware constant > >> propagation" (in addition to some aliasing analysis). If this is > >> what you plan to do in LLVM as well, are you planning on > >> implementing special-purpose passes for these transformations, or > >> re-using existing ones? If you're reusing existing ones, which > >> ones? > >> And how would they need to be modified to become 'OpenMP aware'? > >> > >> Can you please comment on the loop-analysis use case that I > >> outline > >> here: > >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054078.html > >> Would this kind of simplification fall under the 'constant > >> propagation' transformation, or will something else be required? > >> > >> What might be most useful is if we develop a set of optimization > >> tests so that we have a set of use cases from which we can base a > >> design. Do you already have a set of such tests? I'd be happy to > >> work with you on this. > >> > >> Thanks again, > >> Hal > >> > >> > > >> > Yours, > >> > Andrey > >> > > >> > >> -- > >> Hal Finkel > >> Postdoctoral Appointee > >> Leadership Computing Facility > >> Argonne National Laboratory > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > > > -- > > Hal Finkel > > Postdoctoral Appointee > > Leadership Computing Facility > > Argonne National Laboratory >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Possibly Parallel Threads
- [LLVMdev] [RFC] OpenMP Representation in LLVM IR
- [LLVMdev] [RFC] OpenMP Representation in LLVM IR
- [LLVMdev] [RFC] OpenMP Representation in LLVM IR
- [LLVMdev] [RFC] Parallelization metadata and intrinsics in LLVM (for OpenMP, etc.)
- [LLVMdev] [RFC] OpenMP Representation in LLVM IR