search for: parallel_libs

Why is there any motivation to bundle it with unrelated stuff at all? What's the benefit? If it's just to prop up the existence of parallel_libs, then I don't think that makes sense.. Should we move llvm loop optimizations over to parallel_libs as well? If this is just a bikeshed argument, of course chandler will get his way and nobody else matters.. Hopefully, the decision is driven by points like: maintaining a clear modular design,...

...hibatch.sf.net at gmail.com> > Sent: Wednesday, July 27, 2016 9:43:34 PM > Subject: Re: [llvm-dev] RFC: SIMD math-function library > > Why is there any motivation to bundle it with unrelated stuff at all? > What's the benefit? If it's just to prop up the existence of > parallel_libs, then I don't think that makes sense.. I don't think that parallel_libs needs propping - at the moment it is so new that parallel_libs-dev has zero messages. I don't see a strong need for another new top-level project, with whatever administrative overhead that implies. I'm not ag...

...Jul 27, 2016 at 8:46 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I think that everyone is on the same page. We'll put together a patch for > review. > > One remaining question: There seem two potential homes for this library: > parallel_libs and compiler-rt. Opinions on where the vectorized math > functions should live? My inclination is to target it for the new > parallel_libs project, in part because I feel like compiler-rt has too many > things grouped together already, and in part because vectorization is a > form of pa...

...raries devoted to handling parallelism in LLVM (see the README currently checked into the parallel-libs base directory for the project charter). The parallel-libs subproject now has a working git mirror and arcconfig file, so most development workflows should be supported. The mailing lists are: parallel_libs-commits at lists.llvm.org parallel_libs-dev at lists.llvm.org and all future discussions on the subproject will take place there. In particular, checking in of the StreamExecutor source code will be beginning there soon. -------------- next part -------------- An HTML attachment was scrubbed... UR...

Hi everyone, I think that everyone is on the same page. We'll put together a patch for review. One remaining question: There seem two potential homes for this library: parallel_libs and compiler-rt. Opinions on where the vectorized math functions should live? My inclination is to target it for the new parallel_libs project, in part because I feel like compiler-rt has too many things grouped together already, and in part because vectorization is a form of parallel execution. Th...

...ense. Among other things, this makes it straightforward for these libraries to re-use core LLVM libraries where appropriate. ---------------------------------------------- Mailing List and Bugs ---------------------------------------------- Two mailing lists will be set up for the project: 1. parallel_libs-dev at lists.llvm.org for discussions among project developers, and 2. parallel_libs-commits at lists.llvm.org for patches and commits to the project. Each subproject library will manage its own components in Bugzilla. So, for example, there can be several Bugzilla components for different parts...

...straightforward for these libraries to re-use core > LLVM libraries where appropriate. > > > ---------------------------------------------- > Mailing List and Bugs > ---------------------------------------------- > Two mailing lists will be set up for the project: > > 1. parallel_libs-dev at lists.llvm.org for discussions among project > developers, and > 2. parallel_libs-commits at lists.llvm.org for patches and commits to the > project. > > Each subproject library will manage its own components in Bugzilla. So, > for example, there can be several Bugzilla com...

...Subject: Re: [llvm-dev] RFC: SIMD math-function library >> >> Hi everyone, >> >> I think that everyone is on the same page. We'll put together a patch >> for review. >> >> One remaining question: There seem two potential homes for this >> library: parallel_libs and compiler-rt. Opinions on where the >> vectorized math functions should live? My inclination is to target >> it for the new parallel_libs project, in part because I feel like >> compiler-rt has too many things grouped together already, and in >> part because vectorization...

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

Hi all, Okay, the point is whether Intel will publish the source code for their SVML. If Intel will make SVML open-source, there would be not much advantage in incorporating SLEEF into LLVM, since it would be also fairly easy to port SVML to other architectures. If Intel will not open-source SVML, then there could be advantage in using SLEEF for x86 by inlining the functions. Is it possible

On 29 July 2016 at 13:04, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Is it really impossible to just build non-LLVM dependent versions of libc++ or the sanitiser runtimes if they reside in one git megarepo? The more intricate the relationship between the components, the less we'll test for the alternative solutions. My use is solely from a toolchain point

> On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I feel like this thread got a bit stalled. I'd like to pick it up and try to suggest a path forward. > > I don't hear any real objections to the overall idea of having an LLVM subproject for parallelism runtimes and support libraries. I think we should get that created. I think it

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

The 2017 LLVM Developers’ Meeting relies on volunteers to keep things running smoothly. Moderators are critical to this as they keep speakers on track and facilitate Q&A after the talk. I’m looking for community members who would be attending specific talks anyway, to volunteer to moderate the session. If you are interested in volunteering, please respond to this email with your first and

> On 29 Jul 2016, at 21:58, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > > On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote: >> >> I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? > > Your assumption is a downstream