similar to: [LLVMdev] calling c-function with a vector

Yes, changing line 67 of SHLIB as Uwe suggested worked: C:\TEMP>Rcmd SHLIB tryf.f make[1]: `libR.a' is up to date. rm -f -f tryf.a ar cr tryf.a *.o ranlib tryf.a ------- Building tryf.dll from tryf.a -------- echo LIBRARY tryf > tryf.def echo EXPORTS >> tryf.def nm tryf.a > Defs sed -n '/^........ [BCDRT] _/s/^........ [BCDRT] _/ /p' Defs >> tryf.def rm -f Defs

Dear R-help, I'm having problem creating a dll using Rcmd SHLIB with R-1.3.1 on WinNT4: C:\TEMP>Rcmd SHLIB tryf.o make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. C:\TEMP>Rcmd SHLIB tryf.f make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. I

Dear R-help, I'm having problem creating a dll using Rcmd SHLIB with R-1.3.1 on WinNT4: C:\TEMP>Rcmd SHLIB tryf.o make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. C:\TEMP>Rcmd SHLIB tryf.f make[1]: `libR.a' is up to date. make: *** No rule to make target `'tryf.o', needed by `tryf.a'. Stop. I

Since Clang does not seem to allow type casts, such as uchar4 to float4, between vector types, it seems it is necessary to write them as element by element conversions, such as typedef float float4 __attribute__((ext_vector_type(4))); typedef unsigned char uchar4 __attribute__((ext_vector_type(4))); float4 to_float4(uchar4 in) { float4 out = {in.x, in.y, in.z, in.w}; return out; } Running

On Mon, Sep 29, 2008 at 8:11 PM, Mon Ping Wang <wangmp at apple.com> wrote: > The problem with generating insert and extracts is that we can generate poor > code > %tmp16 = extractelement <4 x float> %f4b, i32 0 > %f8a = insertelement <8 x float> %f8a, float %tmp16, i32 0 > %tmp18 = extractelement <4 x float> %f4b, i32 1 > %f8c

Hi, The current definition of shuffle vector is <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> ; yields <n x <ty>> The first two operands of a 'shufflevector' instruction are vectors with types that match each other and types that match the result of the instruction. The third

Hi Dan, Thanks for your comments. I've responded inline below. On 26-Jun-08, at 6:49 PM, Dan Gohman wrote: > On Jun 26, 2008, at 1:56 PM, Stefanus Du Toit wrote: >> >> === >> 1. Shufflevector only accepts vectors of the same type >> >> I would propose to change the syntax from: >> >>> <result> = shufflevector <n x <ty>>

On Jun 27, 2008, at 8:02 AM, Stefanus Du Toit wrote: >>>> <result> = shufflevector <a x <ty>> <v1>, <b x <ty>> <v2>, <d x >>>> i32> >>>> <mask> ; yields <d x <ty>> >>> >>> With the requirement that the entries in the (still constant) mask >>> are >>> within

Prof. Ripley, Seems like mine is 629: c:\home>perl -v This is perl, v5.6.1 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2001, Larry Wall Binary build 629 provided by ActiveState Tool Corp. http://www.ActiveState.com Built 12:27:04 Aug 20 2001 Will try a newer build and see. Regards, Andy > -----Original Message----- >

Hello LLVM Devs, I am starting my PhD on Automatic Parallelization for DSP and want to play with some ARM NEON intrinsics for a start. I spent the last three days trying to compile a version of LLVM that would allow me to compile sources that contain these intrinsics, but with no success. In the process I found out that clang doesn't support NEON (as per

Hi all, I'm currently building a DSL for a computer graphics project that is not unlike NVIDIA's Cg. I have an intrinsic with the following signature float4 sample(texture tex, float2 coords); that is translated to this LLVM IR code: declare void @"sample"(%float4* noalias nocapture sret, %texture, $float2) nounwind readnone The type float4 is basically an array of four

I was investigating an error diagnostic in the following test example: typedef signed char char16 __attribute__((ext_vector_type(16))); void test( char16 srcA, char16 srcB, char16 *dst) { *dst = ( srcA == srcB ); } which produces the message: mismatch.c:5:10: error: assigning to 'char16' from incompatible type 'char __attribute__((ext_vector_type(16)))' *dst = (

Hello guys, Thanks for your help when you are busing. I am working on an open source project. It supports shader language and I want JIT feature, so LLVM is used. But now I find the ABI & Calling Convention did not co-work with MSVC. For example, following code I have: struct float4 { float x, y, z, w; }; struct float4x4 { float4 x, y, z, w; }; float4 fetch_vs( float4x4* mat

In Joe programmer language (i.e. C ;) ), are we basically talking about disallowing: float4 a; float* ptr_z = &a.z; ? Won't programmers just resort to: float4 a; float* ptr_z = (float*)(&a) + 3; ? On Oct 14, 2008, at 3:55 PM, Mon Ping Wang wrote: > Hi, > > Something like a sequential type makes sense especially in light of > what Duncan is point out. I agree

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is

Hi, I've found a case I would expect would optimize easily, but it doesn't. A simple implementation of vector select: float4 simple_select(float4 a, float4 b, int4 c) { float4 result; result.x = c.x ? a.x : b.x; result.y = c.y ? a.y : b.y; result.z = c.z ? a.z : b.z; result.w = c.w ? a.w : b.w; return result; } I would expect this would be optimized to %bool

Correction in the C snippet: typedef signed short v8i16_t __attribute__((ext_vector_type(8))); v8i16_t foo (v8i16_t a, int n) { return a >> n; } Best regards Saurabh On 17 February 2017 at 16:21, Saurabh Verma <saurabh.verma at movidius.com> wrote: > Hello, > > We are investigating a difference in code generation for vector splat > instructions between llvm-3.9

Consider the following C code: typedef __attribute__(( ext_vector_type(2) )) float float2; typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) float float2_align2; void foo(void) { const float * p; size_t offset; float2 tmp = *((float2_align2 *)(p+offset)); } When compiled with clang ‹emit-llvm I get: define void @foo() { entry: %p = alloca float*, align 4

On Tue, Oct 14, 2008 at 1:34 PM, Daniel M Gessel <gessel at apple.com> wrote: > In Joe programmer language (i.e. C ;) ), are we basically talking > about disallowing: > > float4 a; > float* ptr_z = &a.z; > > ? That's my reading as well; the argument for not allowing it is just to make optimization easier. We don't allow addressing individual bits either,

It's been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been