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

On Oct 2, 2012, at 3:09 AM, Andrey Bokhanko <andreybokhanko at gmail.com> wrote: > Chris, > >> My comment was mostly in response to the Intel proposal, which effectively translates OpenMP pragmas directly into llvm intrinsics + metadata. I can't imagine a way to make this work *correctly* without massive changes to the optimizer. > > There are three ways to make this

Andrey Bokhanko <andreybokhanko at gmail.com> writes: > There are three ways to make this work correctly: > > 1) Ignore OpenMP-related intrinsics and associated metadata. Least > effort, least benefit (no OpenMP support). Yet, OpenMP programs > compiled correctly, as if no pragmas are present -- including *exactly > the same* number of routines and call graph (thanks to no

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

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

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

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

Hi All, We'd like to make a proposal for OpenMP representation in LLVM IR. Our goal is to reach an agreement in the community on a simple, complete and extensible representation of OpenMP language constructs in LLVM IR. Hopefully, this would serve as a common ground and would enable further development of OpenMP support both in Clang and LLVM compiler toolchain. We seek feedback on the

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

Andrey Bokhanko <andreybokhanko at gmail.com> writes: > Hi All, > > We'd like to make a proposal for OpenMP representation in LLVM IR. I'm providing some brief comments after a skim of this.. > Our goal is to reach an agreement in the community on a simple, > complete and extensible representation of OpenMP language constructs > in LLVM IR. I think this is a bad

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

Not to distract, but the word, `procedurization' is not an English word. It's just leaping out at me when it is either procedure(s) (noun) or proceduralize (verb). Even processes would make sense. I couldn't help myself because the word was distracting. - Marc P.S. Not that my vote counts, but I'm more in the camp of Hal whose approach to tackling the parallelization

No, just changing defaults -- subject to code reviewers approval. As I said before, I prefer to leave library naming to library pros. Andrey On Fri, May 8, 2015 at 7:21 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > So you plan on switching and enabling the openmp library defaults as > well as changing the openmp library name at the same time? > Jack >

Hi Andrey, Sorry, I definitely misspoke when I said it was likely for OpenMP stuff to end up in this new project. I meant to say that it was possible in the long run, but there are no plans for that now. On Thu, Jun 16, 2016 at 11:55 AM Andrey Bokhanko <andreybokhanko at gmail.com> wrote: > On Thu, Jun 16, 2016 at 9:05 PM, Jason Henline via Openmp-dev < > openmp-dev at

Jack, Alexey [Bataev] promised to send it for review in a day or two. Then it should be approved by code reviewers, which might take some time. andrey Отправлено с iPad > 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Andrey, > Any idea when the patch to enable openmp as the default for > -fopenmp will be posted to

It will come on next week. I'd like to give a chance to everyone to raise their objections first. Yours, Andrey > 8 мая 2015 г., в 18:30, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Is there a proposed patch yet for switching the -fopenmp support over > to the openmp library instead of libgomp? I realize the call to rename > the library may be

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

Hola Chandler, On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev < openmp-dev at lists.llvm.org> wrote: > It seems like if the OpenMP folks want to add a liboffload plugin to > StreamExecutor, that would be an awesome additional platform, but I don't > see why we need to force the coupling here. > > Let me give you a reason: while user-facing sides of

On Wed, Jun 1, 2016 at 8:52 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "C Bergström" <cbergstrom at pathscale.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, "openmp-dev"

On Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ________________________________ > > From: "C Bergström" <cbergstrom at pathscale.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" > <cfe-dev at lists.llvm.org>,

On Wed, Jun 1, 2016 at 11:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "C Bergström" <cbergstrom at pathscale.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, "openmp-dev"