[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]

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

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 will update the bug to note that the we have to change the inliner
and should change the alias analysis. Does someone knows another
module that has to be changed?

>
> Ciao,
>
> Duncan.
>

Cheers,
-- 
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047