similar to: [LLVMdev] OpenMP 3.1 Support Implementation In Clang Is Available

All, Just a heads up that OpenMP 3.1 implementation in clang/llvm compiler is fully complete. Kudos to my colleague from Intel, Alexey Bataev, who wrote most of the code! Apart of Alexey, many other people contributed to this effort; most notably Alexander Musman (also from Intel), who implemented #pragma simd; Mahesha S (then from AMD, now from Samsung), who wrote initial patch that started it

Chandler, Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-) On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at google.com> wrote: > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > No, sorry. libgomp doesn't

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

All, I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp. For reference, the previous discussion is accessible there: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not

Jack, this is not a problem of this patch, this a problem of your configuration. This patch uses standard clang machinery for locating libiomp5 library. Best regards, Alexey Bataev ============= Software Engineer Intel Compiler Team 13.05.2015 15:59, Jack Howarth пишет: > On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >> Jack, >> >> Alexey

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 >

Jack, Could you, please, submit a bug report? -- including steps to reproduce (where you got imageMagick sources, how exactly you compiled them, etc) Andrey On Fri, May 1, 2015 at 3:56 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > > On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: >> >> Chandler,

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

Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject is sustainable going forward without some form of testing support, automated or otherwise. The motivation: It's difficult to make changes to the source without some

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 Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> wrote: > Congratulations! Would you like to add a blurb to the release notes > for the next release? Sure! Will do. Yours, Andrey

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

On Thu, Apr 30, 2015 at 2:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > >> All, >> >> I'd like to resurrect the discussion on replacing libgomp with libiomp as >> the default OpenMP runtime library linked with -fopenmp. >> > > Just for

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

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

Chandler: 1) I completely agree with the comments some others have made about us needing to make it clear that this isn't some Intel-only thing, it’s the LLVM OpenMP runtime. Some suggestions that I think would make sense to help here: … code owner discussion elided since Chris has endorsed Andrey… - Clearly updating the readme and such would be appropriate. Certainly, no problem with

On Mon, May 9, 2016 at 12:04 PM Andrey Bokhanko via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Thanks Jason (and Chandler) to tell Chandler's opinion, though it still > doesn't answer my original question: > > > > Both SE and libomptarget are libraries that handle offloading, not > parallelism. I understand other libraries, to be added in the future, might

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

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