similar to: [LLVMdev] Add a 'notrap' function attribute?

FYI, see also the previous discussion about "speculatable": http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064426.html I think such an attribute should be added. In the thread which lead up to that thread, I proposed using more fine-grained attributes and Michael rightly pointed out the problem with that: you'd need one for every possible form of undefined behaviour. You

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

Hi Nadav, On 10/31/2013 08:53 PM, Nadav Rotem wrote: > data-parallel languages which have a completely different semantics. In > OpenCL/Cuda you would want to vectorize the outermost loop, and the > language guarantees that it is safe to so. Yeah. This is the separate (old) discussion and not strictly related to the problem at hand. Better if-conversion benefits more than OpenCL C

On Nov 1, 2013, at 4:48 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> Hi Nadav, >> >> On 10/31/2013 08:53 PM, Nadav Rotem wrote: >>> data-parallel languages which have a completely different >>> semantics. In >>> OpenCL/Cuda you would want to vectorize the outermost loop, and the >>> language

----- Original Message ----- > Hi Nadav, > > On 10/31/2013 08:53 PM, Nadav Rotem wrote: > > data-parallel languages which have a completely different > > semantics. In > > OpenCL/Cuda you would want to vectorize the outermost loop, and the > > language guarantees that it is safe to so. > > Yeah. This is the separate (old) discussion and not strictly

----- Original Message ----- > > > > On Nov 1, 2013, at 4:48 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > ----- Original Message ----- > > > Hi Nadav, > > On 10/31/2013 08:53 PM, Nadav Rotem wrote: > > > data-parallel languages which have a completely different > semantics. In > OpenCL/Cuda you would want to vectorize

On 11/01/2013 01:48 PM, Hal Finkel wrote: > The large complication that you end up with a scheme like this is > maintaining control dependencies. [...] Good point. > 2. Assert that !notrap cannot be used where its validity might be affected > by control dependencies. Thus, I propose that if this ends up being per-instruction property, its semantics would include this restriction.

On Nov 1, 2013, at 4:48 AM, Hal Finkel <hfinkel at anl.gov> wrote: > 3. Represent the control dependencies explicitly in the metadata. Andy, Arnold (CC'd) and I have been discussing this in a slightly-different context, and briefly, this means adding all of the relevant conditional branch inputs to the metadata, and ensuring dominance before the metadata is respected. For example:

----- Original Message ----- > > > > On Nov 1, 2013, at 4:48 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > 3. Represent the control dependencies explicitly in the metadata. > Andy, Arnold (CC'd) and I have been discussing this in a > slightly-different context, and briefly, this means adding all of > the relevant conditional branch inputs to the

On 01/25/2013 09:56 AM, Nadav Rotem wrote: > Thanks for checking the Loop Vectorizer, I am interested in hearing your > feedback. The Loop Vectorizer does not fit here. OpenCL vectorization is > completely different because the language itself is data-parallel. You > don't need all of the legality checks that the loop vectorizer has. I'm aware of this and it was my point in

On 12/14/2011 02:41 PM, Justin Holewinski wrote: > I would favor calling conventions over metadata for the simple reason > that this maps more cleanly to the device model. Device and kernel > functions are represented differently in PTX, including (sometimes) the > way parameters are passed. For the record, marking the kernels with "calling conventions" instead of metadata

Hello, Chris requested I start a fresh discussion on this, so, here goes. The previous iterations can be found here (and in follow-ups): http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130722/182590.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064047.html Cutting to the chase, the goal is to enhance llvm::isSafeToSpeculativelyExecute() to support call instructions.

Hal, I'm opening a new discussion on vectorization metadata, since it has little to do with fp-math. ;) What kind of metadata would you annotate in the instructions? If I remember from your talk, you're not doing any loop or whole-function analysis, possibly leaving it for Polly to help you along the way. I remember discussing it with Tobias that Polly could have three main steps: 1.

Hi all, On 12/13/2011 10:50 PM, Justin Holewinski wrote: > You mean having no calling convention for device functions, and a new, common > calling convention for kernels? I think this might make sense. One major issue with OpenCL C (and I suppose CUDA) kernels some fail to see is that the functions are "directly callable" (just by choosing a correct the calling convention) in

Hi, I started to play with the LoopVectorizer of LLVM trunk on the work-item loops produced by pocl's OpenCL C kernel compiler, in hopes of implementing multi-work-item work group autovectorization in a modular manner. The vectorizer seems to refuse to vectorize the loop if it sees multiple writes to the same memory object within the same iteration. In case of parallel loops such as the

On 31 Jul 2013, at 10:50, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > This has two main uses: > 1) Intrinsics, including target-dependent intrinsics, can be marked with this attribute – hopefully a lot of intrinsics that do not have explicit side effects and do not rely on global state that is not currently modeled by “readnone” (e.g. rounding

On 07/07/2015 01:32 PM, Renato Golin wrote: > Wouldn't OpenMP account for some of that? At least on a single > machine, could you have both parallel and simd optimisations done on > the same loop? The point in SPMD program description (e.g. CUDA or OpenCL C) autovectorization is to produce something like OpenMP parallel loops or SIMD pragmas automatically from the single thread/WI

On 31 July 2013 11:56, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > The slightly orthogonal question to safety is the cost of execution. For > most intrinsics that represent CPU instructions, executing them > speculatively is cheaper than a conditional jump, but this is not the case > for all (for example, some forms of divide instructions on in-order RISC >

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

Hi Pekka, > Hi, > > I started to play with the LoopVectorizer of LLVM trunk > on the work-item loops produced by pocl's OpenCL C > kernel compiler, in hopes of implementing multi-work-item > work group autovectorization in a modular manner. > Thanks for checking the Loop Vectorizer, I am interested in hearing your feedback. The Loop Vectorizer does not fit here.