search for: float3

Hey Duncan, hey everybody else, I just stumbled upon a problem in the latest llvm-gcc trunk which is related to my previous problem with the 64bit ABI and structs: Given the following code: struct float3 { float x, y, z; }; extern "C" void __attribute__((noinline)) test(float3 a, float3* res) { res->y = a.y; } int main(void) { float3 a; float3 res; test(a, &res); } llvm-gcc -c -emit-llvm -O3 produces this: %struct.float3 = type { float, float, float } define void...

Hi Ralf, > I do not understand why this behaviour is required. What is the problem > in having a function receive a single struct-parameter with three floats > compared to two scalar parameters? > > source-code (C++): > struct Test3Float { float a, b, c; }; > void test(Test3Float param, Test3Float* result) { ... } if you compile this with GCC, you will see that it too

Uh, sorry, did not pay attention where I was replying ;) Hey Duncan, I do not understand why this behaviour is required. What is the problem in having a function receive a single struct-parameter with three floats compared to two scalar parameters? source-code (C++): struct Test3Float { float a, b, c; }; void test(Test3Float param, Test3Float* result) { ... } bitcode:

Hi Ralf, > llvm-gcc -c -emit-llvm -O3 produces this: > > %struct.float3 = type { float, float, float } > define void @test(double %a.0, float %a.1, %struct.float3* nocapture > %res) nounwind noinline { > entry: > %tmp8 = bitcast double %a.0 to i64 ; <i64> [#uses=1] > %tmp9 = zext i64 %tmp8 to i96 ; <i96> [#u...

...seems to use custom LLVM intrinsics, and is built around pure C macros. Clover uses a slightly more complex system, involving a Python script "compiling" a set of built-ins into four files. For example, this declaration (REPL is a macro that does a simple for()) : ---- def vecf : float2 float3 float4 float8 float16 native $type acospi $vecf : x:$type     REPL($vecdim)         result[i] = std::acos(x[i]) / M_PI; end ---- Is compiled to these fragments, one for each vector type (float2, float3, etc) : ---- // In stdlib_def.h : what the OpenCL C kernel sees float2 OVERLOAD acospi(float2...

...fflevector completely generic, and in fact allows even insertelement and extractelement to be represented using it (not that I necessarily think they should be, it's just a nice side effect). If this is feasible, it would be nice to extend it all the way. This lets you do things like: float3 x; float4 y; // ... y.xyz = x; as a single shufflevector, e.g.: %y2 = shufflevector <4xf32> %y1, <3xf32> %x, <4, 5, 6, 3> I assume my proposed generalization can't hurt codegen, since it could always be turned into a sequence of insert and extracts which would pr...

...eric, and in fact allows even insertelement and > extractelement to be represented using it (not that I necessarily > think they should be, it's just a nice side effect). > > If this is feasible, it would be nice to extend it all the way. This > lets you do things like: > > float3 x; > float4 y; > > // ... > > y.xyz = x; > > as a single shufflevector, e.g.: > > %y2 = shufflevector <4xf32> %y1, <3xf32> %x, <4, 5, 6, 3> > > I assume my proposed generalization can't hurt codegen, since it could > always be turned into...

Hi Carlos, On 10/20/11 9:54 AM, Carlos Sánchez de La Lama wrote: >> The project started as a use-case for our "Whole-Function Vectorization" >> library, which allows to transform a function to compute the same as W >> executions of the original code by using SIMD instructions (W = 4 for >> SSE/AltiVec, 8 for AVX). > > Quite interesting. We were planning to

...mething here? class VISIBILITY_HIDDEN MySretAliasAnalysis : public FunctionPass, public AliasAnalysis { std::map<std::string, bool> _srets; public: static char ID; MySretAliasAnalysis() : FunctionPass(&ID) { _srets["sample$int$float2"] = true; _srets["sample$int$float3"] = true; } void getAnalysisUsage(llvm::AnalysisUsage &usage) const { AliasAnalysis::getAnalysisUsage(usage); usage.setPreservesAll(); } bool runOnFunction(Function &F) { AliasAnalysis::InitializeAliasAnalysis(this); return false; } ModRefBehavior getModRefBehavior(C...

...n insertelement and >> extractelement to be represented using it (not that I necessarily >> think they should be, it's just a nice side effect). >> >> If this is feasible, it would be nice to extend it all the way. This >> lets you do things like: >> >> float3 x; >> float4 y; >> >> // ... >> >> y.xyz = x; >> >> as a single shufflevector, e.g.: >> >> %y2 = shufflevector <4xf32> %y1, <3xf32> %x, <4, 5, 6, 3> >> >> I assume my proposed generalization can't hurt codegen,...

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 Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value

Hello, I don't know if you can help me but i tried to install the game but i have an error message after to launch the game. The installation is successful. i did a screen for my error message : [Image: http://pix.toile-libre.org/upload/thumb/1256679788.png ] (http://pix.toile-libre.org/?img=1256679788.png) The problem is during the installation, the game install Visual C++ 2008 and i

On Nov 21, 2012, at 8:55 AM, Relph, Richard wrote: > AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives. > Herewith a terse summary of the change, which we want to improve support of OpenCL for multiple GPUs in a single run-time. > > Conceptually, a serialized archive is really 2 pieces: a few

AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives. Herewith a terse summary of the change, which we want to improve support of OpenCL for multiple GPUs in a single run-time. Conceptually, a serialized archive is really 2 pieces: a few header members and a set of normal file members. There are no constraints on