search for: 058710

...gt; work-item loops. >> >> >> >> [For reference, here's an email in the thread from Spring. This >> discussion >> lead to the parallel loop metadata to mark the data-parallel loops: >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058710.html >> >> The current status of this work is that there's now also effectively >> loop interchange functionality in pocl so the inner (sequential) >> loops >> in the OpenCL C kernels are interchanged with the implicit parallel >> work-item (outer) loops whe...

...d to the problem at hand. Better if-conversion benefits more than OpenCL C work-item loops. [For reference, here's an email in the thread from Spring. This discussion lead to the parallel loop metadata to mark the data-parallel loops: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058710.html The current status of this work is that there's now also effectively loop interchange functionality in pocl so the inner (sequential) loops in the OpenCL C kernels are interchanged with the implicit parallel work-item (outer) loops when it's semantically legal. After this the inner lo...

...on benefits more than OpenCL C > work-item loops. > > > > [For reference, here's an email in the thread from Spring. This > discussion > lead to the parallel loop metadata to mark the data-parallel loops: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058710.html > > The current status of this work is that there's now also effectively > loop interchange functionality in pocl so the inner (sequential) > loops > in the OpenCL C kernels are interchanged with the implicit parallel > work-item (outer) loops when it's semantically...

...on benefits more than OpenCL C > work-item loops. > > > > [For reference, here's an email in the thread from Spring. This > discussion > lead to the parallel loop metadata to mark the data-parallel loops: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058710.html > > The current status of this work is that there's now also effectively > loop interchange functionality in pocl so the inner (sequential) > loops > in the OpenCL C kernels are interchanged with the implicit parallel > work-item (outer) loops when it's semantically...

Hi Pekka, The motivation for the ’notrap’ bit is clear. Domain specific languages can set this bit to enable more aggressive optimizations. I don’t think that the Loop Vectorizer is a good example because it is not designed to vectorize data-parallel languages which have a completely different semantics. In OpenCL/Cuda you would want to vectorize the outermost loop, and the language

Hello, OpenCL C specifies that instructions should not trap (it is "discouraged" in the specs). If they do, it's vendor-specific how the hardware exceptions are handled. It might be also the case with some other (future) languages targeting "streamlined" parallel accelerators in an heterogeneous setting. At least CUDA comes to mind. What about OpenACC and the new OpenMP,