search for: x86_fastcallcc

Functions with __attribute__((fastcall)) pop their arguments and take up to two arguments in ecx and edx. Currently we represent them by just setting the x86_fastcallcc calling convention. The problem is that the ABI has some strange conventions on when a register is used or not. For example: void __attribute__((fastcall)) foo1(int y); will take 'y' in ecx, but struct S1 { int x; }; void __attribute__((fastcall)) foo2(struct S1 y); will use the stack...

...ouble inreg <eax,edx> %x) On Fri, Oct 19, 2012 at 8:17 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > Functions with __attribute__((fastcall)) pop their arguments and take > up to two arguments in ecx and edx. Currently we represent them by > just setting the x86_fastcallcc calling convention. The problem is > that the ABI has some strange conventions on when a register is used > or not. For example: > > void __attribute__((fastcall)) foo1(int y); > > will take 'y' in ecx, but > > struct S1 { > int x; > }; > void __attribute_...

On 5 Oct 2007, at 20:00, Dale Johannesen wrote: >>> I am not to sure on that. because that would make modules compiled >>> with the flag on incompatible with ones compiled without the flag >>> off >>> as stack behaviour would mismatch. >>> It would be no problem to make the behaviour dependent on the -tail- >>> call-opt flag. i am not sure

Dale, > I see. Could we please change its name then? fastcc? > The .ll file uses > x86_fastcallcc for fastcall, for an additional level of confusion. It was made intentionally to outline the target-specific nature of CC. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Gordon. > think there is special support in the LLVM assembly language for these > two. Yes, afair - x86_stdcallcc and x86_fastcallcc > Note that fastcc / CallingConv::Fast is not fastcall. (It's actually > an alias for ccc...) No, at least on x86. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...be trusted? The 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 thi...

On Fri, 5 Oct 2007, Arnold Schwaighofer wrote: >> to me like llvm-gcc honors that. Certainly it should. > > This would imply one fastcc abi (callee pops args on return) to rule > them all? > That is only if fastcall translates to llvm fastcc of course. fastcall != fastcc. fastcall is a well defined convention on x86 that has very specific ABI requirements. fastcc, on the

...fect", SIDEEFFECT); KEYWORD("gc", GC); - + KEYWORD("cc", CC_TOK); KEYWORD("ccc", CCC_TOK); KEYWORD("fastcc", FASTCC_TOK); KEYWORD("coldcc", COLDCC_TOK); KEYWORD("x86_stdcallcc", X86_STDCALLCC_TOK); KEYWORD("x86_fastcallcc", X86_FASTCALLCC_TOK); - + KEYWORD("signext", SIGNEXT); KEYWORD("zeroext", ZEROEXT); KEYWORD("inreg", INREG); @@ -489,7 +491,7 @@ int LLLexer::LexIdentifier() { KEYWORD("nest", NEST); KEYWORD("readnone", READNONE); KEYWORD(&...

...>> >> >> >>> * 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. >> >&gt...

...dent of the > 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 > > >> &g...

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