[llvm-commits] [llvm] r37940 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAGNodes.h include/llvm/ParameterAttributes.h lib/AsmParser/Lexer.l lib/AsmParser/llvmAsmParser.y lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp lib/Target/TargetCallingC

[Rafael Espindola]

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