similar to: [LLVMdev] JIT compiled intrinsics calls is call to null pointer

Hi everyone, I am trying to call an LLVM intrinsic (llvm.pow.f32), inserted with the following call: std::vector<llvm::Type *> arg_types;arg_types.push_back(llvm::Type::getFloatTy(context));auto function=llvm::Intrinsic::getDeclaration(module, llvm::Intrinsic::pow, arg_types);auto result=ir_builder->CreateCall(function, args); When I try to execute the code generated by the JIT

Hi everyone, I have some problems with gettings the X86_thiscall calling convention to work. I am new to LLVM, so if this is the wrong place for this question then I appologise, please tell me where to go instead. I am generating code to call a member function of a class compiled with Microsoft Visual C++ using the JIT compiler. The following code is used to register the pointer to the

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* %ptr1   store float %val1a, float* %ptr2   %val1b = load float* %ptr1   ret float %val1b } define float @B(float * noalias %ptr1,

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*

When I compile attached IR with LLVM 3.6 llc -march=x86-64 -o f.S f.ll it generates an aligned ADDPS with unaligned address. See attached f.S, here an extract: addq $12, %r9 # $12 is not a multiple of 4, thus for xmm0 this is unaligned xorl %esi, %esi .align 16, 0x90 .LBB0_1: # %loop2

Hello, Depending on how I extract integer lanes from an x86_64 xmm register, the backend may spill that register in order to load scalars. The effect was observed on two targets: corei7-avx and btver1 (I haven't checked other targets). Here's a test case with spilling/no-spilling code put on conditional compile: #if __SSE4_1__ != 0 #include <smmintrin.h> #else #include

This load instruction assumes the default ABI alignment for the <4 x float> type, which is 16: %15 = load <4 x float>* %14 You can set the alignment of loads to something lower than 16 in your frontend, and this will make LLVM use movups instructions: %15 = load <4 x float>* %14, align 4 If some LLVM mid-level pass is introducing this load without proving that the vector is

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

Hi all, I'm trying to generate code containing an ordered float compare for equality, and select. The resulting code however has an unordered compare and some Boolean logic that I think could be eliminated. In C syntax the code looks like this: float x, y; int a, b, c if(x == y) // Rotate the integers { int t; t = a; a = b;

Hi, I found that llvm.exp.f32 didn't work but sqrt works well. I implemented a function like define inlinehint float "my_exp"(float %.value) { .body: %0 = call float @llvm.exp.f32(float %.value) ret float %0 } declare float @llvm.exp.f32(float) nounwind readonly But it generates following ASM: 00280072 movups xmm0,xmmword ptr [esp+8] 00280077 movss dword ptr

And also the resulting assembly code is very poor: 00460013 movss xmm0,dword ptr [esp+8] 00460019 movaps xmm1,xmm0 0046001C addss xmm1,xmm1 00460020 pxor xmm2,xmm2 00460024 addss xmm2,xmm1 00460028 addss xmm2,xmm0 0046002C movss dword ptr [esp],xmm2 00460031 fld dword ptr [esp] Especially pxor&and instead of movss (which is

Both ZF and PF will be set if unordered, so the code below is IEEE correct...you want to generate 'fcmp ueq' instead of 'fcmp oqe' This is the resulting x86 assembly code: movss xmm0,dword ptr [ecx+4] ucomiss xmm0,dword ptr [ecx+8] sete al setnp dl test dl,al mov edx,edi cmovne edx,ecx cmovne ecx,esi cmovne

Hi Marc, I'm a bit confused. Isn't the standard compare (i.e. the one for a language like C) an ordered one? I tried converting some C code to LLVM C++ API code with the online demo, and it uses FCMP_OEQ. Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Marc B. Reynolds Sent: Tuesday, 27 May, 2008 14:07 To: 'LLVM

<<<<<<<<<<<<<<<<<<<<<<<<<< ; ModuleID = 'shufxbug.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:6 4-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" define void @sample_test(<4 x float>* nocapture

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from

Using MM registers is wrong unless the user has specifically asked for it, which doesn't seem to be the case here. In the awesome MMX architecture, touching an MM register makes subsequent x87 operations fail unless an EMMS instruction is issued first; none of the compilers here are smart enough to insert EMMS instructions in the right places, so the only safe thing is not to use

On 24 Sep 2007, at 09:18, Evan Cheng wrote: > +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info- > output-file - | grep asm-printer | grep 9 > +; change preceeding line form ... | grep 8 to ..| grep 9 since > +; with new fastcc has std call semantics causing a stack adjustment > +; after the function call > > Not sure if I understand this. Can you illustrate

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

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 Marc, I'm a bit confused. Isn't the standard compare (i.e. the one for a language like C) an ordered one? I tried converting some C code to LLVM C++ API code with the online demo, and it uses FCMP_OEQ. No, if you have: x = NaN y = NaN then the comparison: (x == y) is false. Which is what your seeing from your first post and is the standard IEEE expected behavior.