[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 clattner at apple.com
Tue Jul 17 10:29:52 PDT 2007


On Jul 17, 2007, at 9:45 AM, Rafael Espindola wrote:
>> The problem is that not all "byval" structs get passed in registers.
>> On x86-32 for example, they all get passed on the stack, just a very
>> "specific" part of the stack.
> I think that this can be represented. For example, we would compile  
> the function
>
> int f(int a) { return a; }
>
> on x86-32 into
> ---------------------------------------------------
> %struct.f_frame = type { i32 }
>
> define i32 @f(%struct.f_frame* stack_pointer %p) {
> entry:
>         %tmp2 = getelementptr %struct.f_frame* %p, i32 0, i32 0
>  ; <i32*> [#uses=1]
>         %tmp3 = load i32* %tmp2         ; <i32> [#uses=1]
>         ret i32 %tmp3
> }
> ---------------------------------------------------
>
> Where "stack_pointer" in an attribute that instructs the codegen that
> this is just the esp register. I know that the stack frame is not just
> { i32 }, but I think that the llvm structures are general enough to
> describe it.
>
> On x86_64 the same C code would compile into a llvm function with a
> normal argument.

The problem is on the caller side in this example :).  how does the  
caller do a store into stack memory that doesn't exist?  It will have  
to do an alloca, and that alloca won't be in the right place on the  
stack.

-Chris



More information about the llvm-commits mailing list