similar to: [LLVMdev] Target lowering: how to dump byval argument?

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 the new

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const

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 of making that method

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 as individual ones. We should also make it easier to extend it in the

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

On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > > 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

Hello, I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software development, but I'm not sure if I'm right

I'm unable to figure out how IR attributes can be added via the C++ API. I need to create a function like this:     %1 = call i64 @abi_call_test_tuple_2p(%struct.abi_tuple_2p* byval align 8 %v) Where a structure is being passed by value. I need to add the `byval` attribute somewhere (I'm not clear if this is on the function arguments or the type). I'm also uncertain of why that

As you may have seen, my recent checkins complete implementing this for x86-32. It is possible some of it is not right for Linux, and I'd like to get some testing help. Probably the only thing you'd want to change is LLVM_BYVAL_ALIGNMENT in config/i386/llvm-i386-target.h; at the extreme, if you set that to 0 things should go back to the way they were. The best test I know for

Hello, Dale > Could somebody try this on Linux and investigate any failures other > than the ones above? I'm having here (x866-32/linux): Running /home/asl/proj/llvm/llvm-gcc-4.2/src/gcc/testsuite/g ++.dg/compat/struct-layout-1.exp ... Running /home/asl/proj/llvm/llvm-gcc-4.2/src/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... FAIL: tmpdir-gcc.dg-struct-layout-1/t025

Hi Richard, > In that case if you did want the callee to copy the argument am I right > in thinking that the Frontend would have to pass a pointer and add an > explicit memcpy in the callee? I'm not sure what you are asking. Of course caller or callee can always allocate some temporary on the stack and memcpy to it, then use that copy from then on. The point of byval is that the

> I'm not sure what you are asking. Of course caller or callee can > always allocate some temporary on the stack and memcpy to it, then > use that copy from then on. The point of byval is that the copy is > made where the ABI mandates it for by-value call parameters. If > you don't need to be ABI compatible then there is no point using > byval: it would be better to

On gcc/x86, when a class or struct has a copy constructor or destructor and is passed by value to a function, the caller creates a temporary copy and passes a pointer to the copy. LLVM does the same. msvc++ does not use the pointer trick. It puts the class on the stack like any other function parameter. How to pass a class parameter `byval' while honoring the copy constructor and/or

Hi Arushi, > Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6 > and llvm-gcc 4.2.1, I dont seem to get an aligned variable. does it work with llvm-2.7 (just released)? Ciao, Duncan.

I could not get the same .bc file work with llvm 2.7 on x86_64 either. This is the address I got for a byval argument meant to be aligned to 64byte boundary. 0x7fff3f0ae030 Any more pointers? Arushi PS: Is the IR representation in 2.7 any different, that I should not use the same bitcode file. On Tue, Apr 27, 2010 at 3:22 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi,

Hi, I would like to try to fix LLVM bug 6965<http://llvm.org/bugs/show_bug.cgi?id=6965>, but I am new to the LLVM backend infrastructure. Any pointers on where to start exploring might be useful. Any hints on where such alignments are forced, or where the suspected problem might be will be useful. Thanks in advance Arushi -------------- next part -------------- An HTML attachment was

Duncan wrote: > Hi Alon, > > > The docs say "[byval] indicates that the pointer parameter should > > really be passed by value to the function. The attribute implies > > that a hidden copy of the pointee is made between the caller and > > the callee, so the callee is unable to modify the value in the > > callee." > > > > I am not sure what

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/ee0ae442/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306181842303_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/ee0ae442/attachment.gif>

On 18 June 2013 14:12, Rajesh Viswabramana <rajesh.vis at samsung.com> wrote: > Yes, its soft-float, below is verbose of my command, > Thought so. Any reason to use ARMv4T triple? I don't think you're trying to install Linux on an ARM7TDMI, are you? ;) This look like the default if you just specify "arm" as your triple. We need to get that fixed to some sane value

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/a2502bad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306191201558_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/a2502bad/attachment.gif>