similar to: libomptarget code owner.

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

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

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

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

Dear Duncan, Thank you a lot for your feedback. I have a problem though. The branch weights counters overflow in some files and thus I get incorrect numbers. Is there any way to find a workaround for that? Is is supposed to be a known bug or is it something that needs configuration on my part? Again, thank you a lot for your reply. Best Regards, Georgios Zacharopoulos 2016-02-03 18:23

Dear Duncan, I am generating branch-weights annotated IR files as described in the documentation of LLVM, using profiling with instrumentation. http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation e.g. llvm-profdata merge -output=$(BENCH).profdata default.profraw > clang -S -emit-llvm -O3 -fprofile-instr-use=$(BENCH).profdata -o > bench.prof.ll bench.c The issue is

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

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,

Thanks for your help, Tanya! I haven't created the project in SVN yet. Am I able to set it up myself on the LLVM servers, or does someone else need to do that part? I'll be glad to volunteer to moderate the new mailing lists. We will want a website. I think there will be a top-level docs directory for the project and a docs directory for each subproject. To begin with, StreamExecutor

Yes dmesg | grep "EFI v" [ 0.000000] efi: EFI v2.70 by American Megatrends On Fri, 2020-04-03 at 14:29 -0400, Jonathan Billings wrote: > On Fri, Apr 03, 2020 at 07:37:10PM +0300, Georgios wrote: > > Hi. > > Im trying to set intel_iommu=on on kernel parameters at grub but > > for > > some reason it doesnt work. > > > > I edit

I talked to Chandler about the name "offload_libs" vs "parallel_libs" and he said he thinks "offload" is too narrow of a term for the scope he sees for this subproject. One example he brought up was AVX 512. He thinks that code explicitly targeting CPU parallelism should also be included in this project, even though it doesn't fit in the category of

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