[LLVMdev] Exact meaning of byval

Richard Osborne rlsosborne at googlemail.com
Fri Jul 4 03:15:51 PDT 2008


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 callee, so the callee is unable to modify the value
> in the callee. This attribute is only valid on llvm pointer arguments. It is
> generally used to pass structs and arrays by value, but is also valid on
> scalars (even though this is silly)."
>
> 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, not somewhere in between. In particular, I think byval
> could either mean:
> 	a) The callee is not allowed to modify the argument. If the original code
> 	modifies the argument, the callee should make a copy and modify that
> 	instead.
> 	b) The caller will always pass in a copy of the object, which the callee is
> 	free to modify and will be thrown away afterwards.
>   
Or it could mean:

c) Either a) or b) where the choice is determined by the target when 
lowering calls and arguments. This allows the different targets to do 
different things with this attribute to satisfy their ABI.

(I don't know LLVM well enough yet to comment on which of these is right)
> In both cases, it seems that byval argument must always be a valid pointer.
>
> From the code, I suspect that option b is the case. I would think that option
> a is the better option, since it can prevent copies when the callee doesn't
> even modify the value (but this stems from C ABI or something?)
>   
Conversely option a) allows the caller to not make a copy when there are 
no further uses of the object in the function.
>
> Gr.
>
> Matthijs
>   
Richard



More information about the llvm-dev mailing list