search for: lowercall

...t to send an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this struct, and t...

...--Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Wednesday, May 16, 2012 5:30 PM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to > TargetLowering::LowerCall() so targets have more context in which to > construct call chains > > Thanks. This is going in the right direction IMHO. Obviously, please make sure > you add comments to the data structure and convert all the targets first. > Also, please don't forget to send an email to llvmd...

From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Thursday, April 19, 2012 10:47 AM To: Justin Holewinski Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. We really should think hard about how to i...

...From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains >> >> TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. >> >> We r...

...te: > > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Thursday, April 19, 2012 10:47 AM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains > > TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. > > We really should thi...

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this struct, and t...

All, The attached patch adds two extra arguments to TargetLowering::LowerCall: RetTy and Args. These arguments are used in TargetLowering::LowerCallTo() to construct the Ins and OutVals parameters, but are not available to the target via LowerCall(). Some targets require this additional information, and the LowerCallTo() method is not virtual in TargetLowering. Instead o...

TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. We really should think hard about how to improve the API in two ways. Perhaps we should wrap the arguments in some struct rather than...

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the foll...

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at 3:30 AM, Nikhil Patil wrote: > Hi, > > I am trying to write a LowerCALL() function for my (cu...

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating...

Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it returns a MERGE_VALUES, > i.e. all the results merged along with the chain. Sorry, I don't understand. I am only trying to look at functions that return void here (hence the RetVT == MVT::Other asser...

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of registers and putting them into sensible places for the rest of the function to use. LowerCall is responsible for putting call arguments where callees will expect them and making the cal...

...from [er8] 5 st qr0, [ea] ;; Store the i64 value into the effective address memory location. 6 ;; function epilogue processing here... >From my investigations so far, i64 types should call a custom function in the calling convention for processing this return type. Also, that LowerCall should be modified to have the assigning of frame pointer into er0 and that LowerReturn should be modified in order to store qr0 into the effective address. Please correct me if I'm wrong. My questions are: 1. Are there any target examples that also has this kind of behavior? If there are...

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

Hello, I'm having trouble getting the function prototype of an ExternalSymbolSDNode inside TargetLowering::LowerCall(), this way i could get the original argument sizes before they're legalized into smaller parts. I need this sort of information because depending on the originaltypes of the arguments i need to use some regs or others. I tried using the isSplit flag in ArgFlagsTy but it only marks the first sp...

...ll_native(i32 1, i32 %a) } define void @bar(i32 %a, i32 %b) { call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b) } ... But here I am unsure how to handle the return type of this intrinsic (can it be overloaded to accept any return type?) and whether I can reuse the TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff. Maybe another option is to add some kind of metadata to these function declarations and then check in "LowerCall" whether these metadata flags are present. If so, then extract the funcIdx from metadata and lower this call in a special way. If...

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal&...

Hi all, I am working with the "LowerCall" function, and trying to figure out the types of all the "Outs" arguments. Specifically, I want to find out if a particular "Out[i]" argument is a pointer (of any type), or a regular data type. So far, all pointers show up as the "MVT::i32" datatype, which is not...

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things don't break. so I would like to ask what's the status of tailcalls in...