similar to: [LLVMdev] Code Owner for OpenMP (runtime)

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

Jason, It's great that Google are interested in contributing to the development of LLVM in this area, and that you have code to support offload. However, I'm not sure that all of it is needed, since LLVM already has the offload library which has been being developed in the context of OpenMP, but actually provides a general facility. It has been a part of LLVM since April 2014, and is

On Thu, Apr 30, 2015 at 11:59:52AM +0100, Renato Golin wrote: > Tom, code owner nomination. > > Andrey is the most active developer, so I think it makes sense. How > long do we wait to change the file? Is there any process that you'd > like to follow? > I don't think there is a formal process, but usually the file gets updated once Chris approves. -Tom > cheers,

Am I mistaken in that some .c files must actually be compiled as c++? In file included from openmp-llvm/runtime/src/kmp_ftn_cdecl.c:16: openmp-llvm/runtime/src/kmp.h:210:3: warning: redefinition of typedef 'ident_t' is a C11 feature [-Wtypedef-redefinition] } ident_t; ^ ---------- I previously sent a patch that fixes this and it was completely rejected. IMHO - This must be fixed 1) C

Hearing no opinions to the contrary, let's say Banger's 6pm (tomorrow). Address and web site below. I submitted online for a reservation early this morning, and I'll try to get an updated head count on Sunday morning. -Hal Sent from my Verizon Wireless 4G LTE DROID On Nov 14, 2015 11:21 AM, Chandler Carruth <chandlerc at google.com> wrote: Did this ever get settled? On Fri,

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

Chandler, That raises a more meta-question for me, which is “Why should StreamExecutor be in LLVM at all?” AFAICS, with you approach · It is not a runtime library whose interface the compiler needs to understand. · It does not depend on any LLVM runtime libraries. · It is expected to be used with out-of-tree plugins. If I got all of that right, what connection does it

Hi everyone, There seems to be a good level of interest in this; so we should settle on a time and location. It has been pointed out that previous socials were held at http://bbrovers.com/ - we seem to have a preference for the availability of alcoholic beverages, and otherwise no strong opinions have been expressed. Logistically, we should pick someplace likely to have flexibility regarding

Hi, On Wed, Nov 11, 2015 at 8:01 AM, Cownie, James H via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It would be much more convenient for those of us who are in town for SC and staying downtown if we could find somewhere in walking range. (Which in my mind is 1 to 3/2 of a mile; others may have different criteria, but I find a 30 min walk refreshing after taking beer :-). > Agreed.

On 30 April 2015 at 10:06, Hal Finkel <hfinkel at anl.gov> wrote: >> >> 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: >>

----- Original Message ----- > From: "Sebastian Pop" <spop at codeaurora.org> > To: "James H Cownie" <james.h.cownie at intel.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "John Leidel (jleidel)" <jleidel at micron.com>, "LLVM Dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-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

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 8 February 2016 at 22:56, <cbergstrom at pathscale.com> wrote: > Imho it's critical to get parallel programming working on ARMv8 ( even if it's crappy OMP) to start. Please enable it and I'll run the tests against our internal QA and we can informally handle testing / guarding against regressions. So, I got some dependency errors while building OpenMP on my AArch64 box:

On 26/02/2014 09:03, David Chisnall wrote: > On 25 Feb 2014, at 23:13, Alp Toker <alp at nuanti.com> wrote: > >> 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

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

> What's needed for CPU affinity? We expose his via pthread_attr_setaffinity_np() in <pthread_np.h> - > does the runtime need anything more from the interface, or was this support just not yet a high > priority for you? I'd be happy to help with this support. The Linux code uses the sched_{get,set}affinity calls directly, rather than via the pthread veneer. It can also

> 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

Why is this thread still going? Isn't the most pragmatic choice to just make it a build configuration option and be done? Then whoever is actually packaging it can make the most sensible choice for their needs.. Should I send a patch so this bikeshed thread can die?

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