[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

[Duncan Sands]

Hi Rafael,

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

exactly, and thus alias analysis, inlining etc are all being mislead,
because they will think you are modifying the original.  This is very
dual to StructReturn by the way: if you assign to the sret parameter
before calling the routine, and try to read those values inside the
routine, you get junk.  Likewise here, if you write to the ByVal parameter
inside the routine, then try to read those values outside the routine you
get junk.  This should be at least well documented.

Ciao,

Duncan.