similar to: disabling lib/libomptarget.dylib build?

Haven't seen any discussions here. Does that mean that everybody agree on appointing George Rokos to be the code owner for the projects/openmp/libomptarget source tree? If so, can we have kind of formal approval so that the code_owners.txt file is updated and questions on libomptarget go to the right person then. BTW, the nominee was discussed at the libomptarget developers meeting, and

Hi, Currently libomptarget has no code owner. Although it is part openmp project the expertise required for libomptarget is different from openmp. Georgios Rokos from IBM has agreed to be the owner of libomptarget source, so I would like to nominate Georgios Rokos who is a major contributor to libomptarget. Thanks Ravi -------------- next part -------------- An HTML attachment was

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?

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Roel, You have to checkout and build llvm/clang as usual. For runtime support you'll have to build the libomptarget and make a plugin for your target. Samuel can help you some more. As for the OpenMP examples I can recommend you the http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf look into the target constructs. Sergos On Mon, Jun 8, 2015 at 6:13 PM, Roel Jordans <r.jordans at

Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: > On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers > <release-testers at lists.llvm.org> wrote: >> Start your engines; 6.0.0-rc1 was just tagged. >> >> I know there are still open blockers and it's early in the process in >> a way, but I'd like to find out where we are. Please run the

On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > Start your engines; 6.0.0-rc1 was just tagged. > > I know there are still open blockers and it's early in the process in > a way, but I'd like to find out where we are. Please run the test > script, let me know the results, and upload binaries. At the moment I

Hi, I try to build lldb with Cmake (gcc-5.3.0 is necessary for CUDA) on my "SUSE Linux Enterprise Server 12.2 (x86_64)". Unfortunately the build process breaks for lldb with the below mentioned error message. I've downloaded the following packages and configured with the following commands. svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co

On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > > Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers >> <release-testers at lists.llvm.org> wrote: >>> Start your engines; 6.0.0-rc1 was just tagged. >>> I know there are still open blockers and it's early

On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: >> >> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >>> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers >>> <release-testers at lists.llvm.org> wrote: >>>> Start

Jason, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? Regarding

Hi Carlo, Thanks for helping to clarify this point about libomptarget vs liboffload, I have been getting confused about it myself. I think the open question concerns libomptarget not liboffload (others can correct me if I have misunderstood). My analysis from looking through the code was that libomptarget had some similarities with the platform support in SE, so I just wanted to consider how

Alexandre, Thanks for further shedding some light on the way OpenMP handles dependencies between tasks. I'm sorry for leaving that out of my document, it was just because I didn't know much about the way OpenMP handled its workflows. On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote: > Hi Carlo, > > Thanks for helping to clarify this point about

Hi Sergos, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? If I

On 19 Jan 2018, at 17:11, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: >>> >>> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >>>> On 17 Jan 2018, at 18:53, Hans Wennborg

Jason, > If I understand your interpretation of streams, it does not match my > understanding. SE follows the CUDA meaning of "stream". I think of a stream > as a "work queue" and each device can have several active streams. Memory > space on the device does not belong to any stream, so any stream can access > it. The thing that does belong to the stream is the

I've put together a proposed "charter" for this new project, which I am calling parallel_utils (although I'm very open to suggestions for a better name). The text of my charter is below, and I welcome any input on how it can be improved. ===================================================== LLVM Parallel Utils Subproject Charter

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

Is anyone else seeing this bootstrap failure on current svn trunk? [ 6%] Linking CXX executable ../../bin/llvm-tblgen cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1 /sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time

Ahh, I just noticed that Chandler's proposal is to put SE only into this new project, and to keep libomptarget separately, in OpenMP project. I wonder why so? Why SE (a library serving only one PPM so far) is different from libomptarget (a library also serving only one PPM so far)? Are people have opinion on this? Yours, Andrey ===== Software Engineer Intel Compiler Team On Tue, Apr 26,