similar to: [LLVMdev] Update on OpenMP support in clang / llvm

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

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

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

I'm happy with any representation that works for optimizer. I can prepare a patch for clang to update the 'omp simd' and 'clang loop' CodeGen. We do not use LoopInfo in front-end, but it's no problem to go to the block's single predecessor and attach the metadata there. Regards, Alexander -----Original Message----- From: Tobias Grosser [mailto:tobias at grosser.es]

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

<font size=2 face="sans-serif">Hi Johannes,</font><br><br><font size=2 face="sans-serif">Thank you for the explanation.</font><br><br><font size=2 face="sans-serif">I think we need to clarify some details about code generation in Clang today:</font><br><br><font size=2

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

[This is a cross-posting of a message posted in cfe-dev mailing list ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031595.html); sorry for double-posting.] All, This is to announce availability of a full OpenMP 3.1 support implementation in Clang compiler. The project is hosted there: http://clang-omp.github.com/ It is based on clang 3.3 (and will be updated as new clang/llvm

Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 14:43, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On

You can define clang specific attribute and later add GCC alias for it. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:46, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:38 PM, Alexey Bataev <a.bataev at hotmail.com> wrote: >> >> Francesco, there won't be any duplication. Most of the

Hi Arpith, That is exactly what it is :). My bad, I thought I copied over the libraries to where LIBRARY_PATH pointing but apparently it was copied to a wrong destination. Thanks a lot. On Wed, Jan 20, 2016 at 4:51 AM, Arpith C Jacob <acjacob at us.ibm.com> wrote: > Hi Ahmed, > > nvlink is unable to find the GPU OMP runtime library in its path. Does > LIBRARY_PATH point to

Hi Sergos and Samuel, Thanks for the links, I've got it mostly working now. I still have a problem with linking the code. It seems that the clang driver doesn't pass its library search path to nvlink when linking the generated cuda code to the target library, resulting in it not correctly finding libtarget-nvptx.a. Is there some flag or environment variable that I should set here?

I think it would be great if StreamExecutor could use liboffload to perform its offloading under the hood. Right now offloading is handled in StreamExecutor using platform plugins, so I think it could be very natural for us to write a plugin which basically forwards to liboffload. If that worked out, we could delete our current plugins and depend only on those based on liboffload, and then all the

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

Hi Xinmin, I have updated the clang patch using the standard name mangling you suggested - I was not fully aware of the C++ mangling convention “_ZVG”. I am using “D” for 64-bit NEON and “Q” for 128-bit NEON, which makes NEON vector symbols look as follows: _ZVGQN2v__Z1fd _ZVGDN2v__Z1ff _ZVGQN4v__Z1ff Here “Q” means -> NEON 128-bit, “D” means -> NEON 64-bit Please notice that although

Would it be parallel-libs/libomptarget/ or parallel-libs/omp/libomptarget/ To me the second way seems better because it seems likely that other OpenMP stuff could end up in there in the long run. Once we decide on which code to share, I think we will end up with new directories at the top level for those common components. On Thu, Jun 16, 2016 at 10:59 AM C Bergström <cbergstrom at

> I'd support some of Jame's comments if liboffload wasn't glued to OMP as it is now. I certainly have no objection to moving liboffload elsewhere if that makes it more useful to people. There is no real "glue" holding it there; it simply ended up in the OpenMP directory structure because that was an easy place to put it, not because that's the optimal place for it.

Yes, I understand. I just don't understand why there are 15 review links. as to the format of the list, we previously had a list of feature for 4.5 (before it was fully supported), we can reuse this old format. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:12, Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com> написал(а): > > Alexey, > Johannes want to put all

Hi Francesco, a bit more information. GCC veclib is implemented based on GCC VectorABI for declare simd as well. For name mangling, we have to follow certain rules of C/C++ (e.g. prefix needs to _ZVG ....). David Majnemer who is the owner and stakeholder for approval for Clang and LLVM. Also, we need to pay attention to GCC compatibility. I would suggest you look into how GCC VectorABI can

We could still do that in clang, couldn't we? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Alexey Bataev <a.bataev at outlook.com> Sent: Tuesday, January 22, 2019 12:52:42 PM To: Doerfert, Johannes Rudolf; cfe-dev at lists.llvm.org Cc: openmp-dev at lists.llvm.org; LLVM-Dev; Finkel, Hal J.; Alexey Bataev; Arpith Chacko Jacob Subject: Re: