search for: callingconv

...e 2.7 branches in a couple days. A couple questions: 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. 2) In either case, please document the new calling convention in docs/LangRef.html#callingconv 3) IN X86RegisterInfo.cpp, this patch: if (Is64Bit) { if (IsWin64) - return CalleeSavedRegsWin64; + return (ghcCall ? GhcCalleeSavedRegsWin64 : CalleeSavedRegsWin64); else - return (callsEHReturn ? CalleeSavedRegs64EHRet : CalleeSavedRegs64Bit); + if (ghcCall) +...

...its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will try to work on getting it implemented on SPARC next. > 2) In either case, please document the new calling convention in docs/LangRef.html#callingconv Done. > 3) IN X86RegisterInfo.cpp, this patch: > > if (Is64Bit) { > if (IsWin64) > - return CalleeSavedRegsWin64; > + return (ghcCall ? GhcCalleeSavedRegsWin64 : CalleeSavedRegsWin64); > else > - return (callsEHReturn ? CalleeSavedRegs64EHRet...

...ously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling convention (including allowing it to be used in tail call optimisation). Touches: - lib/Target/X86/X86ISelLowering.cpp - lib/Target/X86/X86FastISel.cpp 3) New calling convention needs different callee save register...

Currently with my understanding of using callingconv.td I still need to lower three functions, FORMAL_ARGUMENTS, CALL, and RET. Is there any known way to have LLVM automagically generate code from tablegen without having to custom lower these functions? The reasoning for this is that all registers are virtual in my backend and I have specified for ll...

...tLowering.h (revision 42247) > +++ include/llvm/Target/TargetLowering.h (working copy) > @@ -851,8 +851,18 @@ > virtual std::pair<SDOperand, SDOperand> > LowerCallTo(SDOperand Chain, const Type *RetTy, bool > RetTyIsSigned, > bool isVarArg, unsigned CallingConv, bool isTailCall, > - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); > + bool isNextInstRet, SDOperand Callee, ArgListTy &Args, > + SelectionDAG &DAG); > + // IsEligibleForTailCallElimination - Check whether the call is &gt...

...t;> To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: >>>>> >>>>> bool isEligibleForTailCallOptimization(Function *F) { >>>>> CallingConv::ID CC = F->getCallingConv(); >>>>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>>>> return true; >>>>> return false; >>>>> } >>>>> >>>>> Any other suggestion...

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

Not sure who owns this bit of code, so sending this to the general list. It looks like there may be an unintentional fall through happening in the X86RegisterInfo::getCallPreservedMask function. http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html case CallingConv::Intel_OCL_BI <http://llvm.org/docs/doxygen/html/namespacellvm_1_1CallingConv.html#a4f861731fc6dbfdccc05af5968d98974ad47327c131a0990283111588b89587cb>: { if (IsWin64 && HasAVX512) return CSR_Win64_Intel_OCL_BI_AVX512_RegMask; if (Is64Bit && HasAVX512)...

...lve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: >>>>>> >>>>>> bool isEligibleForTailCallOptimization(Function *F) { >>>>>> CallingConv::ID CC = F->getCallingConv(); >>>>>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>>>>> return true; >>>>>> return false; >>>>>> } >>>>>> >>>>>&...

...o , >>> >>> To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: >>> >>> bool isEligibleForTailCallOptimization(Function *F) { >>> CallingConv::ID CC = F->getCallingConv(); >>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>> return true; >>> return false; >>> } >>> >>> Any other suggestions are always welcomed. >> >> Why ar...

...o , >>> >>> To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: >>> >>> bool isEligibleForTailCallOptimization(Function *F) { >>> CallingConv::ID CC = F->getCallingConv(); >>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>> return true; >>> return false; >>> } >>> >>> Any other suggestions are always welcomed. >> >> Why ar...

...t;> To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: >>>>> >>>>> bool isEligibleForTailCallOptimization(Function *F) { >>>>> CallingConv::ID CC = F->getCallingConv(); >>>>> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) >>>>> return true; >>>>> return false; >>>>> } >>>>> >>>>> Any other suggestion...

...Hello , >> >> To solve this bug locally I have given preference to tail call >> optimization over local function related optimization in IPRA. I have added >> following method to achieve this: >> >> bool isEligibleForTailCallOptimization(Function *F) { >> CallingConv::ID CC = F->getCallingConv(); >> if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == >> CallingConv::HiPE) >> return true; >> return false; >> } >> >> Any other suggestions are always welcomed. >> >> >> Why aren’t che...

...on 42247) >> +++ include/llvm/Target/TargetLowering.h (working copy) >> @@ -851,8 +851,18 @@ >> virtual std::pair<SDOperand, SDOperand> >> LowerCallTo(SDOperand Chain, const Type *RetTy, bool >> RetTyIsSigned, >> bool isVarArg, unsigned CallingConv, bool isTailCall, >> - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); >> + bool isNextInstRet, SDOperand Callee, ArgListTy &Args, >> + SelectionDAG &DAG); >> + // IsEligibleForTailCallElimination - Check whether...

...== --- include/llvm/Target/TargetLowering.h (revision 42247) +++ include/llvm/Target/TargetLowering.h (working copy) @@ -851,8 +851,18 @@ virtual std::pair<SDOperand, SDOperand> LowerCallTo(SDOperand Chain, const Type *RetTy, bool RetTyIsSigned, bool isVarArg, unsigned CallingConv, bool isTailCall, - SDOperand Callee, ArgListTy &Args, SelectionDAG &DAG); + bool isNextInstRet, SDOperand Callee, ArgListTy &Args, + SelectionDAG &DAG); + // IsEligibleForTailCallElimination - Check whether the call is eligible for + // ta...

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

...ort, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions. make: *** [funccall-1arg.exe] Error 1 While I didn't entirely understand the cause from the backtraces and inspection in the debugger, I did notice that there is not yet a calling convention in CallingConv.h for Fortran, and llvm-convert only tests for CallingConv:C and CSRet, so I suspect that the different CCs is a problem here. It looks like I will have to implement a complement to the FunctionCallArgumentConversion class in llvm-convert.c for the Fortran CC, but I'm not clear on the role of...

...(I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention ("CallingConv::Fast") cannot be called directly from GCC-generated code (n.b. -- standalone gcc, not llvm-gcc) because the fastcc calling convention is, in general, incompatible with GCC (which I assume uses the "CallingConv::C" calling convention). Correct? If not, how do I call a LLVM JIT-gene...

...http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715424 However, there are further build errors for which I haven't found appropriate fixes. It looks like there might be a namespace problem or something, but I'm not a C++ expert. There are problems in Debug.cpp with references to Type, CallingConv, Value, DEFAULT_TARGET_AAPCS_BASED, and others. Below is an excerpt from the build log showing the first reported error. The full build log is available (for a short time) at: http://kojipkgs.fedoraproject.org//work/tasks/3214/5733214/build.log Any help will be greatly appreciated. Thanks!...

...() { int x= call fastcc callee(); //!! caller pops the arguments => stack mismatch callee pops the arguments but caller also wants to pop the arguments of the stack Apparently i forgot to send the answer email to chris reponse. sorry for that. > >> Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately >> that's not controlled by options. Ok then. >> > > Sure it can be, you can set up custom predicates, for example the > X86CallingConv.td file has: > > class CCIfSubtarget<string F, CCAction A> > : CCIf<!strconcat("State.g...