similar to: [LLVMdev] Exact meaning of byval

Matthijs Kooijman wrote: > Hi, > > after working with llvm for a while, I'm still a little confused with the > meaning of the 'byval' attribute. From the langref: > > "This 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

Hi, byval means that the parameter setup code for performing a call copies the struct onto the stack, in an appropriate position relative to the other call parameters. > I'm particularly confused by the "between the caller and the callee" part. The > way I see this, the responsibility for the copying should be with either the > caller or the callee, It is with the caller.

Duncan Sands wrote: > Hi, byval means that the parameter setup code for performing a call > copies the struct onto the stack, in an appropriate position relative > to the other call parameters. > > >> I'm particularly confused by the "between the caller and the callee" part. The >> way I see this, the responsibility for the copying should be with either

> 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

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

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 this means though - when I generate code from the LLVM assembly, do I need to do anything with byval?

LLVM developers, I was wondering if the program would still be safe if I strip the byval attributes from the parameters in the entire bitcode. LLVM language reference manual states that "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. This attribute is only valid on LLVM pointer

Hi Robert, suppose you have a "byval" argument with type T*, and the caller passes a T* called %X for it, while in the callee the argument is called %Y. The IR level semantics are: (1) a copy should be made of *%X. Whether the callee or the caller makes the copy depends on the platform ABI. (2) in the callee, %Y refers to the address of this copy. There are many ways (1) can be

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<0,4>> which

Hi Tim, Thought about it last night and was coming to the same conclusion. 1. it cant be done at the end during lowering (target backend). 2. it should be part of llvm as the byVal needs to be handled. As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee. I may take a look at this. I wonder if it ever emits 'byVal'... I still feel I don't understand

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

Hi Tim, I may be missing something but using CCPassByVal is moving the pointer onto the stack - not what I'm after. I need to add an operation to the function prolog that actually makes a copy of the pointed to data. It is the responsibility of the callee to make the copy, not the caller - hence my trouble. (currently the callee can corrupt the original data viz pass-by-reference!) This

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

Hi Tim, Correction to my last email. What I should have said is that the new pointer is used by the callee rather than the original byVal pointer arg. (the byVal pointer arg remains but is not used by the callee). viz: define void @f1(%struct.tag* byval) { entry: %st = alloca %struct.tag, align 4 %1 = bitcast %struct.tag* %st to i8* %2 = bitcast %struct.tag* %0 to i8* call void

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

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

I missed that the testing case is returning a struct. You are right in VARegSaveSize. For callee: sub sp, sp, #16 push {r11, lr} mov r11, sp sub sp, sp, #8 str r3, [r11, #20] str r2, [r11, #16] str r1, [r11, #12] ldr r1, [r11, #76] The beginning of the input struct @ sp_at_entry - 16 - 8 + 12 = sp_at_entry -12 # of leftover bytes 67-12 = 55 r11+76 is @ sp_at_entry - 24 + 76 = sp_at_entry

Hi Robert, > This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. I've thought that once or twice when dealing with ABIs myself. That's certainly another possibility in your case. You could create a separate FunctionPass that gets executed early on and replaces all byval calls and functions with the correct memcpys. It

On Thu, Dec 6, 2012 at 12:33 AM, Karthik Bhat <karthikthecool at gmail.com> wrote: > Hi David, > > I think it might not be exactly PR13303 which might be causing the > corruption of struct when accessed through GDB. > This seems to be an ABI problem in clang. > The problem seems to be that when we have pass by value of struct > (having indirect arguments) stack is not

Hi, On Wed, Jun 13, 2012 at 9:55 AM, Martinez, Javier E < javier.e.martinez at intel.com> wrote: > Hello,**** > > ** ** > > I’m trying to change the default behavior for how structures are passed to > functions to use pass-by-value. Currently LLVM’s default behavior is to > pass structures by reference. I’m not disputing the benefits of this but I > really want to