search for: x86_thiscal

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 t...

...that I am generating for win32 ABI, which says that the first parameter should be a pointer to the return value: %vec3 = type <{ float, float, float }> define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint alignstack(16) { ENTRY: %"@0" = alloca %vec3, align 4 call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* %v2) ret void } declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 It seems that the code generated by the JIT takes the first parameter for the this value because of the X86_thiscall calling conventio...

...h says that the > first parameter should be a pointer to the return value: > > %vec3 = type <{ float, float, float }> > > define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint > alignstack(16) { > ENTRY: >  %"@0" = alloca %vec3, align 4 >  call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* > %v2) >  ret void > } > > declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 > > It seems that the code generated by the JIT takes the first parameter for > the this value because...

...thiscall convention then you will expect to see something like this: the argument is in the right place, but the caller expects the callee to clean up the stack and the callee expects the caller to do it. In your IR, are the functions that you intend to use as virtual functions declared to use the X86_ThisCall calling convention? David

Hello everyone, I encountered a strange behaviour which I can't explain. I'm developing an application under Windows 7 64bit. This application is using the LLVM library to load and resolve BC files generated with clang. Then the program picks some functions from the module and executes them. That's the theory - but now it's getting strange. The BC files are compiled for 64bit