similar to: [LLVMdev] Disable Short-Circuit Evaluation?

Justin Holewinski <justin.holewinski at gmail.com> writes: > int globalIndexY2 = get_group_id(1)*186 + 6*get_local_id(1) + 2 + 1; > bool valid2       = validX && globalIndexY2 >= 4 && globalIndexY2 < 3910; > > Clang, even at -O0, is performing short-circuit evaluation of these > expressions, resulting in a fair number of branch instructions being >

10.10.2011, 18:29, "David A. Greene" <greened at obbligato.org>: > Justin Holewinski <justin.holewinski at gmail.com> writes: > >>  int globalIndexY2 = get_group_id(1)*186 + 6*get_local_id(1) + 2 + 1; >>  bool valid2       = validX && globalIndexY2 >= 4 && globalIndexY2 < 3910; >> >>  Clang, even at -O0, is performing

Dear Developers, I compiled a OpenCL kernel before (on Nov. last year) like __kernel void g(__global float* array) { array[get_global_id(0)] = 1; } with libclc, which would originally use the instrinsics like llvm.r600.read.local.size.x(). I executed the generated object file with one version of the hsa-runtime [1] provided by Mr. Stellard, when there was more than one workgroup, the output

Hi Mr. Liu, Thanks for your quick reply. I compiled the code with the libclc_trunk and linked the bitcode file under $LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc. After looking into the libclc, it is currently using the new workitem intrinsics (commit ba9858caa1e927a6fcc601e3466faa693835db5e). In the linked bitcode ($LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc), it has the following code segment,

Hey, I want to compute means and standard errors as two tables like this: se<-function(x)sqrt(var(x)/length(x)) object1<-as.data.frame.table(tapply(Data[Year=="1999"],na.rm=T,list(Group[Year=="1999"],Season[Year=="1999"]),mean))

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int x; unsigned int y; int z[BUFFER_LEN]; unsigned int xx[BUFFER_LEN];

>From this bug report (it's a proposal for speedup only, not a bug), https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16895#c6 the fact that you can construct factors with non-unique aka "duplicated" levels in R has been re-raised. As mentioned there, we had a small discussion here (on 'R-devel') a bit more than 7 years ago, where I had said that indeed R core had

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it