search for: libomptarget

Currently trunk fails to build openmp on darwin due to the failure of... [ 46%] Linking CXX shared library ../../../lib/libomptarget.dylib cd /sw/src/fink.build/llvm50-5.0.0-1/build/stage1/projects/openmp/libomptarget && /sw/bin/cmake -E cmake_link_script CMakeFiles/omptarget.dir/link.txt --verbose=1 /sw/src/fink.build/llvm50-5.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-par...

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

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 people do agree he is the best candidate. Thanks, Andrey From...

...; 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 can't compile openmp, since it errors out on > libomptarget: > > /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: > error: use of undeclared identifier 'malloc' > rc = malloc(size); > ^ > /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5: > error: use o...

...s 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 can't compile openmp, since it errors out on libomptarget: /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: error: use of undeclared identifier 'malloc' rc = malloc(size); ^ /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5: error: use of undeclared identifier 'free...

...; 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 can't compile openmp, since it errors out on libomptarget: >> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: >> error: use of undeclared identifier 'malloc' >> rc = malloc(size); >> ^ >> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5: >&...

...re 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 can't compile openmp, since it errors out on libomptarget: >>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: >>> error: use of undeclared identifier 'malloc' >>> rc = malloc(size); >>> ^ >>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src...

I respect Hal's more tactful approach and response.. Let me play devils advocate for a minute 1) Yet another programming model - Is the advantage spelled out somewhere? (I know there are reasons, but I'd like to see a FAQ or this clearly documented. Examples pretty please.. More for long term than my own selfish benefit) 2) Is this an "open standard" - If I wanted to propose a

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

...t enabling parallelism in code and which are also closely tied to compiler technology. Examples of libraries suitable for hosting within the `parallel_utils` subproject are runtime libraries and parallel math libraries. The initial candidates for inclusion in this subproject are StreamExecutor and libomptarget which would live in the `streamexecutor` and `libomptarget` subdirectories of `parallel_utils`, respectively. The `parallel_utils` project will host a collection of libraries where each library may be dependent on other libraries from the project or may be completely independent of any other libra...

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 the kernels storing in memory or on file: the design was originally to provide offload entries within the same object file as host code. It is int...

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

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 understand your interpretation of streams, it does not match my understanding. SE follows the CUDA meaning of "stream". I think of a stream a...

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

...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 can't compile openmp, since it errors out on libomptarget: >>>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: >>>> error: use of undeclared identifier 'malloc' >>>> rc = malloc(size); >>>> ^ >>>> /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openm...

...; wrote: > >> 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 the kernels storing in memory or on file: the design was >> originally to provide offload entries within...

...ism in code and which are also closely tied to > compiler technology. Examples of libraries suitable for hosting within the > `parallel-libs` subproject are runtime libraries and parallel math > libraries. The initial candidates for inclusion in this subproject are > StreamExecutor and libomptarget which would live in the `streamexecutor` > and `libomptarget` subdirectories of `parallel-libs`, respectively. > > The `parallel-libs` project will host a collection of libraries where each > library may be dependent on other libraries from the project or may be > completely independ...

...be built >> separately, without a single unified cmake file. Correct? Also, I expect >> you want all of the libs to be integrated into LLVM build -- correct? This >> should be spelled out explicitly. >> * I don't really like "parallel" in the name. Both SE and libomptarget >> are libraries that handle offloading, not parallelism. I understand other >> libraries, to be added in the future, might deal with parallelism, but >> maybe we need a separate project for them? (Something Chris already >> hinted.) How about "offloading_lib"? &gt...

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

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, 2016 at 6:06 PM,...