[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