search for: x86_thiscallcc

...gt; Do we want to land this now, or wait until the thiscall switch is > actually flipped for MinGW? Maybe combining the patches would be the best? It is funny, I had never tried check-all on mingw. I just did and found some codegen errors, mostly when we look for call void @foo and get call x86_thiscallcc void @foo The only interesting exception is the conversion of lambdas to blocks which fails with the x86_thiscallcc. I wouldn't call this a blocking issue since I don't know of any use of blocks on windows. Attached are the combined patches: My original ones + your fixes + codegen test fi...

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

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

On Tue, Dec 10, 2013 at 5:08 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: >> I think we need to relax the test cases. MSVC usually prints the calling >> convention, and it's often useful information. > > I was going to argue that MSVC doesn't print them, but then I tried, >

...comment makes more sense as the variable name would effectively be blank otherwise. * Item 9 - undocumented calling conventions The following calling conventions are valid tokens but not described in the language references as of revision 223189: intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, x86_64_sysvcc, x86_64_win64cc, kw_ghccc Lastly I'd just like to thank the LLVM developers for all the time and hard work they've put into this project. I'...

...t; >> >>> * Item 9 - undocumented calling conventions >>> >>> The following calling conventions are valid tokens but not described in >>> the language references as of revision 223189: >>> >>> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >>> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >>> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >>> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >>> >>> >>> This is just bitrot. >> >> -- Sean Silva...

...implementation. > > >> >> * Item 9 - undocumented calling conventions >> >> The following calling conventions are valid tokens but not described in >> the language references as of revision 223189: >> >> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >> >> > This is just bitrot. > > -- Sean Silva > > >> >> >>...

...;>>>> The following calling conventions are valid tokens but not described >>>>>>> in >>>>>>> the language references as of revision 223189: >>>>>>> >>>>>>> intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, >>>>>>> kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, >>>>>>> msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, >>>>>>> x86_64_sysvcc, x86_64_win64cc, kw_ghccc >>>>>>> >>>>...