similar to: [LLVMdev] Meaning of byval?

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?

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

On Fri, Dec 16, 2011 at 7:14 PM, Alon Zakai <azakai at mozilla.com> wrote: > > > ----- Original Message ----- >> From: "Eli Friedman" <eli.friedman at gmail.com> >> To: "Alon Zakai" <azakai at mozilla.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Thursday, December 15, 2011 7:02:34 PM >> Subject: Re: [LLVMdev] Emscripten:

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 callee, so the callee is unable to modify the value in the callee.

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

----- Original Message ----- > From: "Eli Friedman" <eli.friedman at gmail.com> > To: "Alon Zakai" <azakai at mozilla.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 15, 2011 7:02:34 PM > Subject: Re: [LLVMdev] Emscripten: LLVM => JavaScript > On Thu, Dec 15, 2011 at 4:10 PM, Alon Zakai <azakai at mozilla.com> > wrote: >

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

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

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.

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

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

Hello, I am seeking a clarification of the semantics of 'byval' parameter attribute in llvm IR. Let's assume the ABI says the caller should create the 'hidden copy' of the pointee. My question is which part of the compiler chain should generate the alloca and copy code. My understanding is that it is the target code generator, not the provider of the llvm IR. But given the

----- Original Message ----- > From: "Sebastian Redl" <sebastian.redl at getdesigned.at> > To: "Alon Zakai" <azakai at mozilla.com> > Cc: "llvmdev" <llvmdev at cs.uiuc.edu>, "Eli Bendersky" <eliben at google.com> > Sent: Wednesday, January 2, 2013 11:44:27 AM > Subject: Re: [LLVMdev] LLVM IR execution in JavaScript >

> 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

> Do all tests need it? Align is just for non-default alignment (> align(1)) so it may be OK for the tests to omit it & it's probably not right to /require/ an align attribute on a byval parameter. I've had to fix some of the tests which checked that the right alignment was applied, by looking at the generated asm, but had no "align A" attributes and relied on the

On 02.01.2013, at 20:50, Alon Zakai wrote: > I agree both are useful approaches. I went with clientside-everything in this demo because I work on that stuff and like it ;) Oh, I agree that it is awesome. It just froze my browser completely for several seconds just compiling the Hello World program. Sebastian

On Mon, Mar 9, 2015 at 12:38 PM, Reid Kleckner <rnk at google.com> wrote: > If we're keeping types on GEP, > You mean rather than just dropping gep entirely & doing manual pointer arithmetic? (& moving inbounds to an attribute on pointer addition, I guess?) > then IMO we should keep them on allocas and globals. It keeps the IR human > readable. > & what of

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