Sorry for the delay... > first let me point out that much of what you say also applies to > StructReturn, which probably can also be used for returning arrays, > ints etc. And like StructReturn this is all about the ABI: my > understanding is that on some platforms the ABI allows for passing > (small) structs by value. We need to be able to support this, but > how? The idea is to treat such parameters as passed by reference, > and add an attribute to tell the code generators to in fact pass them > in whatever way the ABI says they should be. See PR1521. > > Thus in the IR the function is declared to take a pointer to the > struct as an argument, and the ByVal marker is placed for the > benefit of the code generators. However it is not clear to me > that this is semantically correct. Doesn't ByVal mean what it > says: a copy of the struct is made, and if this copy is modified > inside the called function then this does not change the original > struct? But if in the IR we pass in a pointer to the struct, then > any writes to the struct will modify the original, which is wrong.
The way it should work on the code generators is that when compiling a call to a function with a "byval" argument, a copy of the struct is created and placed on the stack. When compiling the function itself, the code generator should use the stack pointer to create a pointer to the *copy* of the structure that was placed on the stack. > Also, I agree that there needs to be more clarity about what is > allowed to be passed ByVal and returned by SRet. I propose that we change the verifier so that it checks that "byval" is only applied to arguments that are pointers to structures. When we find a case were an array should be passed by value, we can easily change the verifier. I will try to write a patch (with a testcase) tomorrow. > Finally, if StructReturn can also return arrays, then I don't mind > to much if ByVal is called StructByVal or something like that. > > Ciao, > > Duncan. Cheers, Rafael _______________________________________________ llvm-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
