similar to: [LLVMdev] Win64 Calling Convention problem

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

Hello > When compiling this module with llc (Intel assembler syntax) I get the > following code. As you can see, the float4 argument is not passed to > the noise-function by pointer. Instead, noise is treated as if it > expected four individual floats as arguments, which are passed in the > registers XMM0-XMM3. That's correct behaviour. ABI under question is C/C++ ABI and it is

All, Attached is a patch that does two things. First it makes the use of the current SSE code a run time option through the use of speex_decoder_ctl() and speex_encoder_ctl It does this twofold. First there is a modification to the configure.in script which introduces a check based upon platform. It will compile in the sse assembly if you are on an i?86 based platform by making a

Hi, I'm trying to compile an intermediate representation file to ASM (intel style), and I believe that the resultant ASM is invalid. The IR is: ; ModuleID = 'test.u' %vec2 = type { float, float } @t = global %vec2 zeroinitializer @x = global i32 0 define i32 @main__i__v() nounwind { locals: %0 = load float* getelementptr inbounds (%vec2* @t, i32 0, i32 0) %1 = fptosi float %0

On Wed, Feb 15, 2012 at 3:36 PM, Matthew Huck <matthew.huck at gmail.com> wrote: > Hi, >   I'm trying to compile an intermediate representation file to ASM (intel > style), and I believe that the resultant ASM is invalid. The IR is: > > ; ModuleID = 'test.u' > > %vec2 = type { float, float } > @t = global %vec2 zeroinitializer > @x = global i32 0 >

libFLAC have three SSE-accelerated functions FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_N (N = 4, 8, 12). They require lpc_order less than N. The best compression preset (flac -8) uses lpc_order up to 12; it means that during encoding FLAC also uses unaccelerated C function. I'm not very familiar with asm so I took FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_12, changed it and

(Changing subject line as diagnosis has changed) I'm attaching the compiled code that I've been getting, both with CodeGenOpt::Default and CodeGenOpt::None . The crash isn't occurring with CodeGenOpt::None, but that seems to be because ECX isn't being used - it still gets set to 0x7fffffff by one of the calls to 76719BA1 I notice that X86::SQRTPD[m|r] appear in

Hi All, In SVN head, MipsISelDAGToDAG.cpp has the following optimization: // Operand is a result from an ADD. if (Addr.getOpcode() == ISD::ADD) { // When loading from constant pools, load the lower address part in // the instruction itself. Example, instead of: // lui $2, %hi($CPI1_0) // addiu $2, $2, %lo($CPI1_0) // lwc1 $f0, 0($2) // Generate: //

Hi Chuck! On Jul 20, 2007, at 11:36 AM, Chuck Rose III wrote: > Hola LLVMers, > > > > I’m looking to make use of the vectorization primitives in the > Intel chip with the code we generate from LLVM and so I’ve started > experimenting with it. What is the state of the machine code > generated for vectors? In my tinkering, I seem to be getting some > wonky

I am fairly certain this is right. Chuck, can you do a quick experiment for me? Go back to your original code but make sure the alloca instruction specify 16-byte alignment. The code should work. If not, please file a bug. Thanks, Evan On Jul 24, 2007, at 1:58 PM, Evan Cheng wrote: > Hrm. This problem shouldn't be target specific. I am pretty sure > prologue / epilogue inserter

On Fri, 20 Jul 2007, Chuck Rose III wrote: > I'm looking to make use of the vectorization primitives in the Intel > chip with the code we generate from LLVM and so I've started > experimenting with it. What is the state of the machine code generated > for vectors? In my tinkering, I seem to be getting some wonky machine > instructions, but I'm most likely just doing

Hrm. This problem shouldn't be target specific. I am pretty sure prologue / epilogue inserter aligns stack correctly if there are stack objects with greater than default stack alignment requirement. Seems to be the initial alloca() instruction should specify 16 byte alignment? Evan On Jul 21, 2007, at 2:51 PM, Chris Lattner wrote: > On Fri, 20 Jul 2007, Chuck Rose III wrote:

Hola LLVMers, I'm looking to make use of the vectorization primitives in the Intel chip with the code we generate from LLVM and so I've started experimenting with it. What is the state of the machine code generated for vectors? In my tinkering, I seem to be getting some wonky machine instructions, but I'm most likely just doing something wrong and I'm hoping you can set me in

Here's the optimized versions: $ opt -std-compile-opts unopt-pass.ll -o - | llvm-dis -o - [...] define %3 @_ZN7WebCore15GraphicsContext19roundToDevicePixelsERKNS_9FloatRectE(%"class.WebCore::GraphicsContext"* %this, %"struct.WebCore::FloatRect"* %rect) nounwind ssp align 2 { %roundedOrigin = alloca %"class.WebCore::FloatSize", align 4 ;

Hi, It doesn't compile with yasm, or nasm (reports invalid combination of opcode and operands), and mov _x,EAX is meaningless as _x is just a label (an numeric constant that happens to be an address), so it would have to be dereferenced to get to the memory at that address, otherwise it's like saying mov 0x12341234, EAX Now, my asm skills are not that great, so I'm prepared to be

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think

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

Hello all, I'm working on a prototype LLVM pass that would take a function operating on 'magic' vectors and produce a function operating on concrete vectors. For example, given vadd function operating on magic 17-element vectors: typedef float vfloat __attribute__((ext_vector_type(17))); vfloat vadd(vfloat a, vfloat b) { return a+b; } it should produce vadd operating on 4-element

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 Fri, Oct 7, 2011 at 2:15 PM, andrew adams <andrew.b.adams at gmail.com> wrote: > Hi all, > > I'm having trouble understanding how llvm determines if pointers > alias. Consider the following two functions that each do a redundant > load: > > define float @A(float * noalias %ptr1) { >   %ptr2 = getelementptr float* %ptr1, i32 1024 >   %val1a = load float*