search for: tgrosser

On 9 March 2015 at 17:30, Tobias Grosser <tgrosser at inf.ethz.ch> wrote: > If my memories are right, one of the critical issues (besides > other engineering considerations) was that parallelism metadata in LLVM is > optional and can always be dropped. However, for > OpenMP it sometimes is incorrect to execute a loop sequential that...

Since SPIR can be (easily) transformed to NVVM IR at least for me this helps a lot. Thank you Tobias. -MH On January 12, 2015, Tobias Grosser <tgrosser at inf.ethz.ch> wrote: > On 12.01.2015 05:48, Jonathan Ragan-Kelley wrote: > > This question is specifically motivated by the practical constraints of > > NVVM, but I don't know anywhere better to ask (hopefully, e.g., > > @jholewinski is still following), and I believe...

This question is specifically motivated by the practical constraints of NVVM, but I don't know anywhere better to ask (hopefully, e.g., @jholewinski is still following), and I believe it concerns general LLVM issues: NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL text parsers are from that generation. It's interface calls for adding modules as either bitcode

I'm part of a research group at MIT looking to create an extension of LLVM that inherently allows one to nicely code a parallel loop. Most parallel frameworks tend to take the body of a parallel loop and stick it inside of a function for the parallel runtime to call when appropriate. However, this makes optimizations significantly more difficult as most compiler optimizations tend to be