search for: omp4

...penMP 4 offloading is still young. ditto > OpenMP 4 offloading does not yet > have a real user community agreement > yet because the first implementations just > started shipping very recently. Partially strongly disagree - Maybe you meant on Power8? Intel has had their support for OMP4 for quite some time. It may have been buggy and focused on simd directive, but as best I can tell they have worked quite hard to fix bugs and improve it. (Shameless self promotion) We have had some degree of OMP4 offloading for like 1.5 years now.. It's mostly targeting the GPU and x86, but al...

...et >> > have a real user community >> >> agreement >> >> > yet because the first implementations just >> > started shipping very recently. >> >> Partially strongly disagree - Maybe you meant on Power8? >> Intel has had their support for OMP4 for quite some time. It may have >> been buggy and focused on simd directive, but as best I can tell they >> have worked quite hard to fix bugs and improve it. > > I meant across many platforms. Intel had preliminary support for OpenMP 4 offloading directives even before OpenMP 4...

...gt;> agreement >> >> >> >> > yet because the first implementations just >> >> > started shipping very recently. >> >> >> >> Partially strongly disagree - Maybe you meant on Power8? >> >> Intel has had their support for OMP4 for quite some time. It may >> >> have >> >> been buggy and focused on simd directive, but as best I can tell >> >> they >> >> have worked quite hard to fix bugs and improve it. >> > >> > I meant across many platforms. Intel had prel...

The thread has lost focus and cherry picking replies.. To restate things since maybe you missed my points ---- 1) SE is a programming model and needs a home of it's own. Having a programming model with it's headers and all other stuff glued into a runtime project which intends to be universal and PM agnostic doesn't make sense. 1.1) The more I look, the most it seems SE is just a

On 08/11/14 07:32 PM, Das, Dibyendu wrote: > Storing llvm-ir in the fat binary may have the same performance issues mentioned below. The fat binary discussed in the proposal has provision for storing the isa/llvm-ir. My point is instead of llvm-ir it shd be something like spir. Ok - so lets see some data. #1 Benchmarks showing at least SPIR dgemm/sgemm performance #2 Some logical explanation

> On Mar 28, 2016, at 10:18 AM, C Bergström <cbergstrom at pathscale.com> wrote: > > On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> Hi Jason, >> >> This is probably because I'm not aware of the details, but it was claimed in >> this thread that liboffload can target Xeon Phi and Nvidia GPUs.

On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Hi Jason, > > This is probably because I'm not aware of the details, but it was claimed in > this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a > new library that the compiler has to be aware of has to bring significant > benefit. > So it is not clear

On Thu, Jun 2, 2016 at 11:47 AM, Chandler Carruth <chandlerc at google.com> wrote: > (Mostly trying to re-focus the thread somewhat) > > Given support from Mehdi, Renato, and especially Hal who has contributed > specifically in this area to LLVM as a whole, and no strong objections from > significant contributors (I feel like the primary concerns Intel raised have > been