[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

[Chris Lattner]

On Jul 9, 2007, at 9:21 AM, Rafael Espindola wrote:
>> 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.
> Yes, it is nice can of worms :-(
>
> For the alias analysis, we would be assuming two pointer might alias
> when they do not. Might generate worst code, but not incorrect code.
>
> The inliner will have to be modified to create a copy of the structure
> when inlining functions with byval arguments.

Yes, I think these need to be aware of byval and do the right thing  
with it.

> The only clean solution I can think of is making the stack
> manipulation explicit in the IL. If I recall correctly, SMLNJ does
> something similar.
>
> With this approach, in order to pass something on the stack (be it a
> structure or not), one would explicitly allocate the stack frame and
> pass the stack pointer as explicit argument. I like this approach very
> much, but it is a hell lot more work.

I actually don't like this approach, because this depends a lot of  
decisions made in the code generator: the copy may be in registers  
(hopefully) or on the stack, or with some magic funny thing.  Adding  
an extra copy at the llvm level would require the codegen to remove  
it, which is really hard.

-Chris